Steven Schveighoffer wrote:
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.
A question: in C#/Java, can you have annotations on function pointer and
delegate declarations?
void foo( int delegate(int) pure dg) {
...
}
What would this look like with annotations?
(The underlying question is, how do annotations interact with the type
system?)
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.
Yes, but then they're just keywords, with an @ in front. You'd just be
kidding yourself if you think you've reduced the keyword count.
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
