Le 08/11/2012 11:56, Walter Bright a écrit :
> On 11/7/2012 11:27 PM, Jacob Carlborg wrote:
>> On 2012-11-08 02:49, Walter Bright wrote:
>>
>>> Yes, that makes the attribute global.
>>
>> I don't actually know how this works in Java but if you are forced to
>> use the
>> fully qualified name for the attribute it won't make the attribute
>> global.
>>
>
> A plugin would apply globally, wouldn't it?

No it would apply on symbols qualified with a given attribute (provided by the plugin).

On 11/9/2012 6:28 PM, deadalnix wrote:
> Le 08/11/2012 11:56, Walter Bright a écrit :
>> On 11/7/2012 11:27 PM, Jacob Carlborg wrote:
>>> On 2012-11-08 02:49, Walter Bright wrote:
>>>
>>>> Yes, that makes the attribute global.
>>>
>>> I don't actually know how this works in Java but if you are forced to
>>> use the
>>> fully qualified name for the attribute it won't make the attribute
>>> global.
>>>
>>
>> A plugin would apply globally, wouldn't it?
>
> No it would apply on symbols qualified with a given attribute (provided by the
> plugin).

Meaning a given attribute can have only one, global, meaning.

On 2012-11-10 05:02, Walter Bright wrote:

> Meaning a given attribute can have only one, global, meaning.

Isn't that true for any symbol. Can I have two std.stdio.writeln symbols in the same application?

-- 
/Jacob Carlborg

Le 10/11/2012 05:02, Walter Bright a écrit :
> On 11/9/2012 6:28 PM, deadalnix wrote:
>> Le 08/11/2012 11:56, Walter Bright a écrit :
>>> On 11/7/2012 11:27 PM, Jacob Carlborg wrote:
>>>> On 2012-11-08 02:49, Walter Bright wrote:
>>>>
>>>>> Yes, that makes the attribute global.
>>>>
>>>> I don't actually know how this works in Java but if you are forced to
>>>> use the
>>>> fully qualified name for the attribute it won't make the attribute
>>>> global.
>>>>
>>>
>>> A plugin would apply globally, wouldn't it?
>>
>> No it would apply on symbols qualified with a given attribute
>> (provided by the
>> plugin).
>
> Meaning a given attribute can have only one, global, meaning.

Yes, it have to. What is the point of attaching an attribute is you cannot know what meaning it has ?

If an attribute can have ambiguous meaning, then it defeat the whole point of having attribute.

On 11/10/2012 1:59 AM, Jacob Carlborg wrote:
> On 2012-11-10 05:02, Walter Bright wrote:
>
>> Meaning a given attribute can have only one, global, meaning.
>
> Isn't that true for any symbol. Can I have two std.stdio.writeln symbols in the
> same application?
>

Think of it this way. If I have myString.String, and use the strings in it as an attribute in one module, and in another use module use myString.String as an attribute with a totally different meaning, that will not work if plugins are used.

On 2012-11-10 20:04, Walter Bright wrote:

> Think of it this way. If I have myString.String, and use the strings in
> it as an attribute in one module, and in another use module use
> myString.String as an attribute with a totally different meaning, that
> will not work if plugins are used.

I'm not entirely sure what you're meaning here but if you have two symbols with the same name in two different modules their fully qualified names won't be the same.

If you're referring to using a string literal as an attribute then that would be a bad thing, like we have tried to explain. It's better to use a type which will have a unique name.

If I have misunderstood what you're meaning could you provide a code example?

-- 
/Jacob Carlborg

Le 10/11/2012 20:04, Walter Bright a écrit :
> On 11/10/2012 1:59 AM, Jacob Carlborg wrote:
>  > On 2012-11-10 05:02, Walter Bright wrote:
>  >
>  >> Meaning a given attribute can have only one, global, meaning.
>  >
>  > Isn't that true for any symbol. Can I have two std.stdio.writeln
> symbols in the
>  > same application?
>  >
>
> Think of it this way. If I have myString.String, and use the strings in
> it as an attribute in one module, and in another use module use
> myString.String as an attribute with a totally different meaning, that
> will not work if plugins are used.

Thinking of it this way don't make any sense. The whole point of an attribute is to tell a library about how to understand your code.

If many library uses the same attribute, then it defeat the whole point of having attribute. This is why the discussion about disallowing any type as UDA exists in the first place.

On 11/10/2012 11:15 AM, Jacob Carlborg wrote:
> On 2012-11-10 20:04, Walter Bright wrote:
>
>> Think of it this way. If I have myString.String, and use the strings in
>> it as an attribute in one module, and in another use module use
>> myString.String as an attribute with a totally different meaning, that
>> will not work if plugins are used.
>
> I'm not entirely sure what you're meaning here but if you have two symbols with
> the same name in two different modules their fully qualified names won't be the
> same.
>
> If you're referring to using a string literal as an attribute then that would be
> a bad thing, like we have tried to explain. It's better to use a type which will
> have a unique name.
>
> If I have misunderstood what you're meaning could you provide a code example?
>

That is what I mean, and it also applies to a library type which different modules may press into service as attributes.

On 11/10/2012 12:21 PM, deadalnix wrote:
> Thinking of it this way don't make any sense. The whole point of an attribute is
> to tell a library about how to understand your code.
>
> If many library uses the same attribute, then it defeat the whole point of
> having attribute. This is why the discussion about disallowing any type as UDA
> exists in the first place.

I understand that. I just am not convinced of the scope of this issue, and I am not convinced that a runtime attribute system is that applicable for this case, nor am I convinced that exception handling is that applicable (all for reasons already explained).

For another analogy, consider the type "int". Different modules impute different meanings into it all the time, and it doesn't cause terrible compatibility problems between modules.

Walter Bright:

> consider the type "int". Different modules impute different meanings into it all the time, and it doesn't cause terrible compatibility problems between modules.

The usage of naked basic types as int and double cause troubles. Haskell programmers avoid some of them defining strong types like this (this syntax also allows you to specify exactly what operations you want to be allowed on this new type, with that "deriving"):

newtype Angle = A Double
    deriving (Eq, Ord, Num, Fractional)

Similarly you can also tell apart angles represented in degrees from angles in radians, and avoid some bugs. (It's possible to overdo this idea, and make the code too much fussy and not handy to write, so you have to keep some balance and not use too many new types).

A possible D syntax, using std.typecons.Typedef:

alias Angle = SubTypedef!(double, Eq, Ord, Num);

That equals to:
alias Angle = Typedef!(double, Subtype, Eq, Ord, Num);

Where Eq, etc, are pre-defined template mixins that implement different operations, like equality, opCmp, etc, that Typedef mixes in.

Bye,
bearophile