On Tuesday, 11 June 2013 at 20:31:22 UTC, Jacob Carlborg wrote:
On 2013-06-11 18:12, QAston wrote:
I agree that attributes should have types - that way it's
easily
recognizable what are they for in code. "Anonymous" attributes
seem to
me to be sort of like "you can throw ANYTHING in c++" feature
- it's
there, but probably without a sane use case.
Could you explain to me what's the benefit of the @attribute
convention
you introduce? It seems non-obvious to me.
It shows the intent of the type. D both have a keywords to
indicate an interface and an abstract class. In C++ interfaces
and abstract classes are possible as well, but there's no real
way to tell that a given class is actually supposed to be used
as an interface.
I was kind of disappointed with the way D implemented UDA's.
Just dump any value/type to a symbol.
Ok, i see the point now, thanks :). Maybe it'd be worth to
enforce that convention on a language level, let's say: only
types with @attribute can be used as UDA. One reason for making
that restriction is that when there's more than a one way of
doing something people will do that using all the ways possible.
This may be a problem to code which uses many libraries
simultanously - your utility functions will not interoperate with
UDAs made by someone else.
BTW I've just found one use case for anonymous UDA:
@(Enum.Entry) is verbose, the question is: "Is it useful enough
to keep it, or maybe having single convention is better?"
Certainly, there's no need to have arbitrary types in attributes
like
@UnawareClass because you can do @TakeUnaware!(UnawareClass)
instead.
The other way around would be to operate on
@SerializationAttribute specific to the lib so you can fetch only
the attributes you're interested in easily.
