User Defined Attributes

[Leandro Lucarella]

Timon Gehr, el 14 de November a las 17:25 me escribiste:
> On 11/14/2012 03:31 PM, Leandro Lucarella wrote:
> >Tove, el 14 de November a las 13:55 me escribiste:
> >>>struct UserProfile {
> >>>    @Id(1) i32 uid;
> >>>    @Id(2) string name;
> >>>    @Id(3) string blurb;
> >>>}
> >>>
> >>>Where Id is "thrift.attributes.Id" or something similar.
> >>
> >>well, similar... but beginning with a symbol...
> >>
> >>[thrift.attributes.Definition]
> >>struct UserProfile
> >>{
> >>   [1] i32 uid;
> >>   [2] string name;
> >>   [3] string blurb;
> >>}
> >
> >OK, that's just a good example of convenience of allowing native types, but I
> >think it is still potentially harmful. What if you pass that struct to another
> >library that have another meaning attached to int annotations? How could you
> >tell that library that this particular int annotations is not for it?
> >...
> 
> By not telling it that they are for it. Note that the
> [thrift.attributes.Definition] annotation is significant.

Yes, but that only tells thrift how to interpret those ints, it doesn't tell
any other module they *shouldn't* interpret them. Or are you suggesting every
module that want to attach meaning to an int attribute should check if the
parent module doesn't have any other attribute attached to it?

> >I mean, it convenient to be able to throw numbers or strings too:
> >
> >void f() { throw 1; }
> >
> >void g() { throw "error"; }
> >
> >int main()
> >{
> >	try {
> >		g();
> >	} catch (char[] e) {
> >		writefln(e);
> >	}
> >	try {
> >		f();
> >	} catch (int i) {
> >		return i;
> >	}
> >	return 0;
> >}
> >
> 
> What he does is more like (but not exactly like):
> 
> class ThriftException{
>     int x;
>     this(int x){ this.x = x; }
> }

I don't know what does this mean.

--