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).
The compiler can recognize special annotations and put them to the name
mangling. It may even mangle general purpose annotations.
