November 07, 2012
On Wednesday, November 07, 2012 13:01:52 Jacob Carlborg wrote:
> On 2012-11-07 12:05, Leandro Lucarella wrote:
> > OK, that's another thing. And maybe a reason for listening to people
> > having
> > more experience with UDAs than you.
> > 
> > For me the analogy with Exceptions is pretty good. The issues an conveniences of throwing anything or annotating a symbol with anything instead of just type are pretty much the same. I only see functions making sense to be accepted as annotations too (that's what Python do with annotations, @annotation symbol is the same as symbol = annotation(symbol), but is quite a different language).
> I start to more and more think it would be better to explicitly require the developer to declare an attribute, like:
> 
> attribute foo
> {
>      string name;
> }
> 
> @foo("asd") int a;

Isn't that how it works in Java? It's been a while since I've done much with Java, but IIRC that's essentially how it works in Java.

- Jonathan M Davis
November 07, 2012
On 2012-11-07 13:08, Jonathan M Davis wrote:

> Isn't that how it works in Java? It's been a while since I've done much with
> Java, but IIRC that's essentially how it works in Java.

Yes, exactly, just with a slightly different syntax.

http://docs.oracle.com/javase/1.5.0/docs/guide/language/annotations.html

-- 
/Jacob Carlborg
November 07, 2012
Le 07/11/2012 05:19, Walter Bright a écrit :
> On 11/6/2012 7:52 PM, bearophile wrote:
>> Walter Bright:
>>
>>> But I'm not sure at this point if that is the right thing to do.
>>
>> Why?
>
> D was fortunate in having 10 years of experience with C++'s exception
> system to learn from. We don't have that with UDAs.
>
>
>> [If you decide to restrict UDAs, then later it will be easy to extend
>> them, it
>> will not break code. While doing the opposite break code. It's you the
>> one that
>> has taught me to design things this way :-) ]
>
> It's a good point, but I have no experience with UDAs. There may be
> emergent behavior with these features that is completely unexpected, and
> we wouldn't find out about it without having it there.
>

I don't think that is a good idea. As attribute as they are defined agglomerate in a tuple, without correct typing, it is impossible to determine for a piece of code which attributes belongs to the current processing or not.

For instance, let say that I'm writing a lib using attributes. I expect int attribute to be attached to a symbol and does some processing on it. If another dev of another lib decide to do the same, then it is is now impossible to use both libs together.


Unless we decide up front, by convention, what an int attribute means. But even in this case, it is risky. As my experience shown in the past, using convention to ensure certain property in the some code usually fail.

> Yes, I know it's a risk.
>
> (And it was a no-brainer to restrict the exception types. But one must
> be careful in drawing analogies in programming, as different things are,
> well, different and can be different in unexpected, surprising ways.)
>

November 07, 2012
Le 07/11/2012 13:01, Jacob Carlborg a écrit :
> On 2012-11-07 12:05, Leandro Lucarella wrote:
>
>> OK, that's another thing. And maybe a reason for listening to people
>> having
>> more experience with UDAs than you.
>>
>> For me the analogy with Exceptions is pretty good. The issues an
>> conveniences
>> of throwing anything or annotating a symbol with anything instead of just
>> type are pretty much the same. I only see functions making sense to be
>> accepted
>> as annotations too (that's what Python do with annotations,
>> @annotation symbol
>> is the same as symbol = annotation(symbol), but is quite a different
>> language).
>
> I start to more and more think it would be better to explicitly require
> the developer to declare an attribute, like:
>
> attribute foo
> {
> string name;
> }
>
> @foo("asd") int a;
>

Yes that was pretty close to what my proposal looked like in the big annotation thread, except I used @ttribute .
November 07, 2012
Le 07/11/2012 10:13, Timon Gehr a écrit :
> On 11/07/2012 08:08 AM, Daniel Murphy wrote:
>> "Walter Bright" <newshound2@digitalmars.com> wrote in message
>> news:k7cko9$hes$1@digitalmars.com...
>>> On 11/6/2012 6:10 PM, Daniel Murphy wrote:
>>>> My thoughts exactly. It reminds me of the horror of C++ exceptions. I
>>>> think it would be reasonable to require every annotation is a struct or
>>>> class.
>>>
>>>
>>> Good analogy. But I'm not sure at this point if that is the right
>>> thing to
>>> do.
>>
>> I don't know if it will turn out to be useful either. But if it's left in
>> there, right or wrong, people will use it and it will be impossible to
>> remove later.
>>
>> If two libraries both use string literal annotations for metadata (and
>> they
>> will) you can no longer use both on the same declaration at once. This
>> leads back to C/C++'s global namespace.
>>
>> As an example:
>> [3] class Blah {}
>> What on earth is 3? Why would you want to attach 3 to a class
>> declaration?
>> How many different ways are there for libraries to interpret this?
>>
>> Most importantly, if users still want to experiment with anonymous
>> annotations, they still can:
>> [tuple(3)] class Blah {}
>
> Then what does this particular restriction buy?
>
>> Adding speculative features with no use case in mind is a recipe for
>> disaster.
>>
>> Much like how you can use extern(C) to force global visibility, you can
>> still get the less hygienic behaviour, if you explicitly ask for it.
>>
>> We lose nothing. If it turns out this was the wrong call, built-in types
>> can be restored without breaking a single line of code.
>>
>
> That is never a given in D.
>
> static assert(!is(typeof({struct S{ [2] int x; }})));
>

I'd argue that is expression is the problem here, not really the annotation.
November 07, 2012
Le 07/11/2012 09:23, Don Clugston a écrit :
> If you mean, we should be working on getting the existing stuff working
> before we think about adding more stuff, I agree 100%.

That is a good part of my point. The other part being that surprise feature dropped in master, not only impair stability, but also impair the ability for developing tooling around D.

My problem isn't the feature itself. I'm all for annotation. But the way it is added in the language make nonsense and is even dangerous for D.

> I would say we're about three years away from it being sensible to work
> on annotations.
> It's reasonable to draft a preliminary proposal (A roadmap, what a novel
> concept!). But I think it would be a big mistake to do much work on it.
>

Exactly. And propose the feature in an experimental branch or something before pushing it to master, so people can test it, it can be refined as needed and 3rd party tool can adapt to it.
November 07, 2012
"Timon Gehr" <timon.gehr@gmx.ch> wrote in message news:k7d8n1$1o69$1@digitalmars.com...
>>
>> Most importantly, if users still want to experiment with anonymous
>> annotations, they still can:
>> [tuple(3)] class Blah {}
>
> Then what does this particular restriction buy?
>

It makes it harder to do the wrong thing.


November 07, 2012
On 11/7/2012 4:01 AM, Jacob Carlborg wrote:
> I start to more and more think it would be better to explicitly require the
> developer to declare an attribute, like:
>
> attribute foo
> {
>      string name;
> }
>
> @foo("asd") int a;

Adding a whole new aggregate type is a pretty intrusive and major change.

November 07, 2012
Le 07/11/2012 21:35, Walter Bright a écrit :
> On 11/7/2012 4:01 AM, Jacob Carlborg wrote:
>> I start to more and more think it would be better to explicitly
>> require the
>> developer to declare an attribute, like:
>>
>> attribute foo
>> {
>> string name;
>> }
>>
>> @foo("asd") int a;
>
> Adding a whole new aggregate type is a pretty intrusive and major change.
>

So let's defined in object.d the following :

@attribute struct attribute {}

And then mark as @attribute anything that may used as attribute.

@attribute struct foo {
	string name;
}

@foo("asd") int a;

If wasn't marked as @attribute, it wouldn't be an valid attribute.
November 07, 2012
On 11/7/2012 3:05 AM, Leandro Lucarella wrote:
> For me the analogy with Exceptions is pretty good. The issues an conveniences
> of throwing anything or annotating a symbol with anything instead of just
> type are pretty much the same.

That's a good point, I just want to wryly remark on the consistency argument that UDAs should work everywhere, but the inconsistency argument that they should not work for basic types :-)


> I only see functions making sense to be accepted
> as annotations too (that's what Python do with annotations, @annotation symbol
> is the same as symbol = annotation(symbol), but is quite a different language).

Just functions? I thought one big use of UDAs was to mark classes as "serializable".