thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Haberman <step...@exigencecorp.com>
Subject Re: const bug
Date Mon, 23 Aug 2010 21:27:21 GMT

> I think this one falls under the category of "reasonable, but
> currently unimplemented feature."

Upon closer examination, we had been using Thrift version
20080411-exported and the compiler accepted the previous input, but
actually generated the wrong result.

Given the previous thrift definitions, it was accepted, but B ended up
having:

    public B() {
      this.a = new A();
    }

When we assumed it had something like:

    public B() {
      this.a = Constants.DEFAULT_A;
    }

We were lucky in that when we defined DEFAULT_A, we did not change
any of its defaults, as in my example, so it was defined as:

    public class Constants {
      public static final A DEFAULT_A = new A();
    }

Meaning we got the behavior we desired, by mere chance.

It is nice that the compiler is stricter now, in that we're not allowed
to use a feature that does not exist. :-)

Thinking a bit more about it, having const structs as a default value
poses the question: should the const be copied or just referenced? If it
is just reference, mutating the const struct instance would affect any
previously-constructed structs that were using it as a default value.
Which could be a surprising behavior.

I can open a ticket for this feature--any thoughts on whether the
default value being a const struct should result in same reference or
new copy semantics?

Thanks,
Stephen


Mime
View raw message