DIP6: Attributes
Ary Borenszweig
ary at esperanto.org.ar
Mon Aug 3 08:42:33 PDT 2009
Don wrote:
> 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).
But the DIP I wrote isn't about general-purpose annotations. It's just
the first step. Are "pure" and "nothrow" part of the mangling? Or which
are? I thought not. Can you overload a pure and a not-pure function with
the same parameter count and types?
Anyway, I'll write some more about attributes in the abstract or rationale.
More information about the Digitalmars-d
mailing list