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