Proposal: user defined attributes

Walter Bright newshound2 at digitalmars.com
Sun Mar 18 17:41:38 PDT 2012


On 3/18/2012 2:58 PM, Jacob Carlborg wrote:
> Ok, now to the user defined attribute:
>
> @attribute class NonSerialized {} // This is what's called a "marker" in Java.
> It doesn't contain any information, the information is the type itself.
>
> @attribute class SerializeAs
> {
> string value;
> }
>
> class Base
> {
> int x;
> @SerializeAs(foo) int y;
> @NonSerialized int c;
> }
>
> @NonSerialized class Sub : Base
> {
> int z;
> }
>
> Base sub = new Sub;
> serialize(sub);
>
> In this example the user defined attribute "NonSerialized" indicates that the
> class shouldn't be serialized. When the serializer is serializing "sub" the
> compile time type will be "Base" therefore it would need to use runtime
> reflection to also serialize the fields added in the subclass "Sub". To check if
> the object should be serialized the serializer need to be able to access user
> defined attributes using runtime reflection.

I'm sorry, I find this *massively* confusing. What is foo? Why are you 
serializing something marked "NonSerialized"? I really have no idea what is 
going on with this. What is the serialize() function? How does any of this tell 
you how to serialize an int? How is Base.c also a NonSerialized with c in a 
superclass of it?

??????????????????????????????????

Maybe this is why I don't much care for attributes - it's all just a fog to me 
what is happening.


More information about the Digitalmars-d mailing list