Don escribió:
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?)
In C# (and they were going to add it to Java) you can annotate a lof of
things: declarations, statements, function arguments. I don't know if
expressions.
So you could do:
void foo(@pure int delegate(int) dg) {
}
but that'll mark as pure the argument dg, not the type of dg. That
doesn't mean there shouldn't be a way to annotate types.
