thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Duxbury <br...@rapleaf.com>
Subject Re: const bug
Date Mon, 23 Aug 2010 21:30:57 GMT
Generally I would be leaning towards the copy approach.

On Mon, Aug 23, 2010 at 2:27 PM, Stephen Haberman
<stephen@exigencecorp.com>wrote:

>
> > 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message