DIP6: Attributes

[Ary Borenszweig]

Don escribió:
> Steven Schveighoffer wrote:
>> On Mon, 03 Aug 2009 11:42:33 -0400, Ary Borenszweig 
>> <ary at esperanto.org.ar> wrote:
>>
>>> 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?
>>
>> Yes, they have to be.  There are reasons besides overloading for 
>> including other attributes in the naming.
>>
>> For example, if a function is pure, then becomes unpure, you don't 
>> existing code that is expecting a pure function to link against it.
>>
>> In other words, the linker is dumb.  It only knows how to match 
>> symbols, so you have to embed into the symbols the important pieces of 
>> the interface that you want the linker to consider important.
> 
> 
> A question: in C#/Java, can you have annotations on function pointer and 
> delegate declarations?
> 
> void foo( int delegate(int) pure dg) {
>   ...
> }
> What would this look like with annotations?
> 
> (The underlying question is, how do annotations interact with the type 
> system?)

In C# (and they were going to add it to Java) you can annotate a lof of 
things: declarations, statements, function arguments. I don't know if 
expressions.

So you could do:

void foo(@pure int delegate(int) dg) {
}

but that'll mark as pure the argument dg, not the type of dg. That 
doesn't mean there shouldn't be a way to annotate types.