DIP6: Attributes

Don nospam at nospam.com
Mon Aug 3 08:31:35 PDT 2009


Ary Borenszweig wrote:
> Don escribió:
>> grauzone wrote:
>>> Don wrote:
>>>> Ary Borenszweig wrote:
>>>>> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6
>>>>
>>>> This looks like a solution in search of a problem. What's the 
>>>> problem being solved?
>>>
>>> Attaching additional data to types, that can't be specified 
>>> otherwhere. This should help with metaprogramming-like stuff.
>>>
>>> For example serialization. How do you specify that a field shouldn't 
>>> be part of the serialized data? Java has an extra keyword attribute like
>>> "transient" (comes from before attributes were introduced). C# uses 
>>> what we call annotation in this thread. How would you do this in D?
>>
>> I agree that there doesn't seem to be a nice way at present. One 
>> possibility would be to establish a naming convention for transient 
>> fields -- a Ruby-style solution, I guess.
>>
>> But are annotations actually an ideal solution for this problem?
>> Presumably, you'll have to specify that somewhere else anyway. I mean, 
>> during reading it will need to either be initialized separately after 
>> serialisation (like opPostBlit, perhaps?), or else remain 
>> uninitialized. Serialisation seems to be _extremely_ similar to 
>> construction. I'm not sure that annotations capture that.
>>
>> D has much more powerful metaprogramming than C# or Java, so my 
>> intuition and hope is that we shouldn't need to adopt hacks from those 
>> weaker languages. The annotation syntax in C# and Java looks like an 
>> ugly hack to me. Purely a subjective opinion, of course, but it seems 
>> really out of place in a C-family language.
> 
> Attributes has many, many other uses. Appart from serialization, you 
> could specify how a field is stored in a database. How a method maps to 
> an http request (post, get, which parameters to bind to the request, 
> etc.). Whether a method should do security checks before executing. 
> Whether a method should be run as a test, and what's the expected 
> exception to be thrown. [insert your usage here]

Great, you've answered my question. That should be in the DIP, instead 
of the vague stuff that's in there now -- the existing DIP is about 
replacing keywords, which is very unconvincing. (It doesn't work, 
actually -- the name mangling is important for most of the keywords 
mentioned).



More information about the Digitalmars-d mailing list