Custom attributes (again)
Timon Gehr
timon.gehr at gmx.ch
Fri Apr 6 03:43:27 PDT 2012
On 04/06/2012 12:28 PM, Walter Bright wrote:
> On 4/6/2012 3:23 AM, Manu wrote:
>> What about:
>>
>> struct editor
>> {
>> this(string name, EditType, Colour = Colour.Default, string
>> description = null)
>> {
>> //...
>> }
>>
>> blah blah blah
>> }
>>
>> @attr(editor("thing",...blah...))
>
> Are you really changing the arguments for every declaration? Or is it
> one set that is repeated everywhere?
>
Yes, allowing the arguments to be different is a crucial feature.
Custom attributes are not a boolean thing, that is just the case for
built-in ones. They are arbitrary data that is attached to a declaration
and can then be used to build powerful semantics using compile time
reflection.
>
>> I don't see the advantage over:
>> @editor(...)
>>
>> ?
>
> Name collisions with other @ attributes.
>
Which other attributes? Built-in ones? Otherwise, the D module system
will be great at disambiguating the collisions as soon as inaccessible
private symbols do not participate in symbol name collisions any more.
Maybe we could just keep all the lower case @attributes reserved in
order to be future proof.
More information about the Digitalmars-d
mailing list