On Mon, 03 Aug 2009 11:42:33 -0400, Ary Borenszweig <a...@esperanto.org.ar>
wrote:
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).
But the DIP I wrote isn't about general-purpose annotations. It's just
the first step. Are "pure" and "nothrow" part of the mangling? Or which
are? I thought not. Can you overload a pure and a not-pure function with
the same parameter count and types?
Yes, they have to be. There are reasons besides overloading for including
other attributes in the naming.
For example, if a function is pure, then becomes unpure, you don't
existing code that is expecting a pure function to link against it.
In other words, the linker is dumb. It only knows how to match symbols,
so you have to embed into the symbols the important pieces of the
interface that you want the linker to consider important.
To answer Don's point, there is nothing saying that the compiler can't
read attributes and change its behavior. Of course, those would have to
be builtin attributes.
My opinion on removing existing keywords is -- don't. There's little to
no gain. Let that ship sail, and concentrate on future keyword proposals.
-Steve
