Re: DIP6: Attributes
Steven Schveighoffer Wrote: What I'd like to see is something like this possible: void foo (int timeout, string bar, float f = 4.0); void foo(int timeout); call!(foo)(timeout=5,bar=\hello\); Taking into account the default value of f, what the parameters are named, and which overload to call. I could certainly do it with C#. In .net reflection needs no compile time support, it's fully runtime. You don't always have full type information at compile time, unless you want to restrict reflection to compile-everyting-to-one-big-pile scenario.
Re: DIP6: Attributes
On Wed, 05 Aug 2009 07:20:38 +0400, Benji Smith dlangu...@benjismith.net wrote: Frank Benoit wrote: Andrei Alexandrescu schrieb: Ary Borenszweig wrote: call!(foo)(5, hello) with varaidic args? Well some don't like to need to remember the order of arguments. Andrei Assigning the argument by name instead of order has two other benefits, i can think of... 1. on the call side, it is documented for what the given values are used. 2. it may be possible to let all parameters have default values and for example just give a value for the last parameter. This is not possible with just the parameter order. But these aren't issues with reflection. These are just the same function calling rules applied elsewhere in the language: 1) If you want to call a function: you must know its name. 2) If you want to pass parameters: you must know the correct order. I can't imagine a circumstance where someone uses reflection to call a function and knows how to create the correct set of arguments, but doesn't know what order to put them in. --benji They are mostly used with optional parameters: void foo(int x = -1, int y = 42, bool b = false); foo(b: true);
Re: DIP6: Attributes
Jacob Carlborg wrote: On 8/4/09 18:55, Steven Schveighoffer wrote: On Tue, 04 Aug 2009 12:23:41 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Steven Schveighoffer wrote: On Tue, 04 Aug 2009 09:45:51 -0400, grauzone n...@example.net wrote: Steven Schveighoffer wrote: don't think it's worth adding them until we can have full reflection capabilities so we can get at elements of code and therefore get the annotations associated with it. I see much more usefulness for annotations as reflection hints than as a replacement for keywords. But we already have full reflection. It's called __traits. You can build a serialization library or proper (user friendly?) reflection on top of it. I think you are the 1 millionth person to say it, and yet we still do not have a user friendly reflection system. Why is that? You'd think that if it could be done, somebody would have done it by now. The reality is there's quite few of us. D is not in the stage where if something could be done, somebody somewhere has done it or is working on it. That's understandable, nobody can expect a language as young as D to have everything. But in reality, I think the *theory* that everything is there to build a reflection system is only proven when it actually happens. I'm sure when the enterprising person or persons go to develop it, they will find pieces missing from the static reflection system. So my point is that adding annotations before reflection works and is implemented makes little sense to me, because the usage of them will be crippled by the fact that reflection isn't complete. What I'd like to see is something like this possible: void foo (int timeout, string bar, float f = 4.0); void foo(int timeout); call!(foo)(timeout=5,bar=\hello\); Taking into account the default value of f, what the parameters are named, and which overload to call. I could certainly do it with C#. -Steve You mean like this: http://tango.pastebin.com/m129241b0 ? /Jacob Carlborg static assert(jacobCarlbord.ninjaLevel == BlackBelt);
Re: DIP6: Attributes
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
Re: DIP6: Attributes
Don wrote:
...
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?
Well, Java doesn't HAVE delegates and C# doesn't (AFAIK) allow you to
define them inline; they have a special declaration syntax that can't be
used in an expression.
C# would probably look something like:
namespace Blech
{
[Pure]
public delegate int Moo(int);
public class Urk
{
public static void foo(Moo dg) {
...
}
}
}
(The underlying question is, how do annotations interact with the type
system?)
I don't think they form part of the type; they're just sort of attached
to that particular declaration.
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.
I suspect the reasoning goes like this:
* I want attributes. Walter doesn't see the use.
* Walter complains about adding keywords.
* I can make keywords look like attributes, and then I get attributes!
:P
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
Re: DIP6: Attributes
Daniel Keep wrote: 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. I suspect the reasoning goes like this: * I want attributes. Walter doesn't see the use. * Walter complains about adding keywords. * I can make keywords look like attributes, and then I get attributes! :P The idea is just stolen from C#/Java. I guess the idea is that 1. keywords/annotations are in a different namespace and 2. even compile time keyword annotations can be handled as normal identifiers. The second point means introducing a new keyword is like declaring a new identifier in object.d. But it would also allow users shadowing annotation keywords by defining their own annotations, which might be a problem or not.
Re: DIP6: Attributes
grauzone Wrote: Daniel Keep wrote: 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. I suspect the reasoning goes like this: * I want attributes. Walter doesn't see the use. * Walter complains about adding keywords. * I can make keywords look like attributes, and then I get attributes! :P The idea is just stolen from C#/Java. I guess the idea is that 1. keywords/annotations are in a different namespace and 2. even compile time keyword annotations can be handled as normal identifiers. The second point means introducing a new keyword is like declaring a new identifier in object.d. But it would also allow users shadowing annotation keywords by defining their own annotations, which might be a problem or not. IIRC, in C# you can use keywords as identifiers. int @if = 3; // this is a variable called if the @ in C# is a way to tell the parser - don't treat this as a keyword.
Re: DIP6: Attributes
Steven Schveighoffer Wrote: 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 If we are willing to have our own specialized linker format than the compiler can output data structures that contain a symbol with an assosiated map of attributes (meta-data). This will remove the need to have mangled symbols. For example, the compiler can provide to the linker the dependency graph as attributes.
Re: DIP6: Attributes
grauzone Wrote: inheritance? You want to inherit annotations? What for? Backward compatibility: obtain annotation cast it, work with it, then later change its type. Annotations will be used by reflection, so classinfo will be useful.
Re: DIP6: Attributes
Don Wrote: Annotations are useful in many ways, but without full reflection capabilities, they are restricted to things that can read them via source code, and so they are no better than comments. This is a very, very important observation, and I think it belongs in the DIP. It means that it probably doesn't make much sense to implement annotations without also having an intention to implement full-blown reflection. The DIP is about the first step: to allow syntax.
Re: DIP6: Attributes
Don Wrote: 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. The problem with keywords is they're global. Why do you think there is module std.string, but there isn't core.stdc.wchar? It's because string is not a keyword, while wchar is. And annotations are also identifiers (though predefined, like Object) rather than keywords.
Re: DIP6: Attributes
Daniel Keep Wrote: Which one works right now and doesn't require you first spend at least a year convincing Walter that it's useful, then convincing him it's necessary As far as I see, necessity is not questioned. It may be only of low priority or something like that.
Re: DIP6: Attributes
Kagamin wrote: Don Wrote: 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. The problem with keywords is they're global. Why do you think there is module std.string, but there isn't core.stdc.wchar? It's because string is not a keyword, while wchar is. And annotations are also identifiers (though predefined, like Object) rather than keywords. No, that's only one of the problems with keywords. Prefixing all new keywords with __ solves the same problem, and it's no more ugly than prefixing with @. But it doesn't solve the other keyword problems.
Re: DIP6: Attributes
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.
Re: DIP6: Attributes
Tue, 04 Aug 2009 17:22:50 +1000, Daniel Keep wrote:
Don wrote:
...
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?
Well, Java doesn't HAVE delegates and C# doesn't (AFAIK) allow you to
define them inline; they have a special declaration syntax that can't be
used in an expression.
C#:
Listint ls;
ls.Sort((x, y) = y - x);
or
ls.Sort((x, y) = { int a; a = y; a -= x; return a; });
Re: DIP6: Attributes
Sergey Gromov wrote:
Tue, 04 Aug 2009 17:22:50 +1000, Daniel Keep wrote:
Don wrote:
...
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?
Well, Java doesn't HAVE delegates and C# doesn't (AFAIK) allow you to
define them inline; they have a special declaration syntax that can't be
used in an expression.
C#:
Listint ls;
ls.Sort((x, y) = y - x);
or
ls.Sort((x, y) = { int a; a = y; a -= x; return a; });
That's not a delegate type, that's a delegate literal.
Re: DIP6: Attributes
On Tue, 04 Aug 2009 03:03:12 -0400, Don nos...@nospam.com wrote:
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?)
I'm not familiar with Java annotations, it's been a while since I used
Java.
In C#, you would not use an attribute as a type modifier, the attributes
are attached to a declaration (e.g. a class, member, function parameter).
So basically, an attribute can modify how the compiler treats something,
but it doesn't allow you to define new types with it. I suppose you could
use it that way, but I think it would be better to just use it as hints
and information, not an integral part of the type system.
When you have runtime reflection, you can query for attributes on almost
anything, but they are usually descriptors, and don't affect type
matching. The only places I've used it are as hints to other things
reading my compiled objects. For example, SerializableAttribute is used
by serializers to know what to serialize and what not to serialize.
If pure weren't part of the function signature, but simply a way to
compile a function, then it would be fine as an annotation.
A good usage for annotation, for example, would be scope, since it simply
indicates where the compiler should put things, and doesn't affect types
or signatures.
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.
keywords are global, that was one of Walter's main points against adding a
keyword for properties. Since annotations necessarily have a different
syntax than normal symbols, you don't have to worry about avoiding those
words. Others have also said that adding a builtin annotation would be
easier because it doesn't affect the parser.
For the record, I'm not really keen on using annotations for *everything*
as some people have suggested. They have good uses, but I don't think
it's worth adding them until we can have full reflection capabilities so
we can get at elements of code and therefore get the annotations
associated with it. I see much more usefulness for annotations as
reflection hints than as a replacement for keywords.
-Steve
Re: DIP6: Attributes
Steven Schveighoffer wrote: For the record, I'm not really keen on using annotations for *everything* as some people have suggested. They have good uses, but I Me neither, but I think they'd be a worthy feature. Of course, there are far more pressing issues, but if Walter has time to introduce const/immutable/pure, then why not annotations? don't think it's worth adding them until we can have full reflection capabilities so we can get at elements of code and therefore get the annotations associated with it. I see much more usefulness for annotations as reflection hints than as a replacement for keywords. But we already have full reflection. It's called __traits. You can build a serialization library or proper (user friendly?) reflection on top of it.
Re: DIP6: Attributes
Kagamin wrote: grauzone Wrote: inheritance? You want to inherit annotations? What for? Backward compatibility: obtain annotation cast it, work with it, then later change its type. Annotations will be used by reflection, so classinfo will be useful. Code can do that at compiletime. No need for casting, because the tuple returned by __traits will use the correct types directly. For runtime, I have no idea. The D crowd seems to prefer compile time. We got __traits instead of more detailed TypeInfo/ClassInfo. If you want to do runtime stuff, you'll have to generate your own RTTI using compile time code.
Re: DIP6: Attributes
Tue, 04 Aug 2009 22:46:22 +1000, Daniel Keep wrote:
Sergey Gromov wrote:
Tue, 04 Aug 2009 17:22:50 +1000, Daniel Keep wrote:
Don wrote:
...
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?
Well, Java doesn't HAVE delegates and C# doesn't (AFAIK) allow you to
define them inline; they have a special declaration syntax that can't be
used in an expression.
C#:
Listint ls;
ls.Sort((x, y) = y - x);
or
ls.Sort((x, y) = { int a; a = y; a -= x; return a; });
That's not a delegate type, that's a delegate literal.
Sorry, you said: C# doesn't ... allow you to define them (delegates)
inline. Delegate literal *is* an inline definition of a delegate.
What you say now is that C# doesn't allow to define a delegate type
inside a function which is definitely true and is very annoying.
Re: DIP6: Attributes
Sergey Gromov wrote:
Tue, 04 Aug 2009 22:46:22 +1000, Daniel Keep wrote:
Sergey Gromov wrote:
Tue, 04 Aug 2009 17:22:50 +1000, Daniel Keep wrote:
Don wrote:
...
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?
Well, Java doesn't HAVE delegates and C# doesn't (AFAIK) allow you to
define them inline; they have a special declaration syntax that can't be
used in an expression.
C#:
Listint ls;
ls.Sort((x, y) = y - x);
or
ls.Sort((x, y) = { int a; a = y; a -= x; return a; });
That's not a delegate type, that's a delegate literal.
Sorry, you said: C# doesn't ... allow you to define them (delegates)
inline. Delegate literal *is* an inline definition of a delegate.
What you say now is that C# doesn't allow to define a delegate type
inside a function which is definitely true and is very annoying.
Have you seen the Func delegates? They are exactly for that.
The above example would be:
void foo(Funcint, int dg) { ... }
Re: DIP6: Attributes
Tue, 04 Aug 2009 11:58:27 -0300, Ary Borenszweig wrote:
Sergey Gromov wrote:
Tue, 04 Aug 2009 22:46:22 +1000, Daniel Keep wrote:
Sergey Gromov wrote:
Tue, 04 Aug 2009 17:22:50 +1000, Daniel Keep wrote:
Don wrote:
...
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?
Well, Java doesn't HAVE delegates and C# doesn't (AFAIK) allow you to
define them inline; they have a special declaration syntax that can't be
used in an expression.
C#:
Listint ls;
ls.Sort((x, y) = y - x);
or
ls.Sort((x, y) = { int a; a = y; a -= x; return a; });
That's not a delegate type, that's a delegate literal.
Sorry, you said: C# doesn't ... allow you to define them (delegates)
inline. Delegate literal *is* an inline definition of a delegate.
What you say now is that C# doesn't allow to define a delegate type
inside a function which is definitely true and is very annoying.
Have you seen the Func delegates? They are exactly for that.
The above example would be:
void foo(Funcint, int dg) { ... }
Func defines a delegate with one argument and a non-void return. There
are lots of others like Action, Predicate, Comparator etc. which you
must either remember or look up every time you need a specific delegate
signature.
Re: DIP6: Attributes
Sergey Gromov wrote:
Tue, 04 Aug 2009 11:58:27 -0300, Ary Borenszweig wrote:
Sergey Gromov wrote:
Tue, 04 Aug 2009 22:46:22 +1000, Daniel Keep wrote:
Sergey Gromov wrote:
Tue, 04 Aug 2009 17:22:50 +1000, Daniel Keep wrote:
Don wrote:
...
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?
Well, Java doesn't HAVE delegates and C# doesn't (AFAIK) allow you to
define them inline; they have a special declaration syntax that can't be
used in an expression.
C#:
Listint ls;
ls.Sort((x, y) = y - x);
or
ls.Sort((x, y) = { int a; a = y; a -= x; return a; });
That's not a delegate type, that's a delegate literal.
Sorry, you said: C# doesn't ... allow you to define them (delegates)
inline. Delegate literal *is* an inline definition of a delegate.
What you say now is that C# doesn't allow to define a delegate type
inside a function which is definitely true and is very annoying.
Have you seen the Func delegates? They are exactly for that.
The above example would be:
void foo(Funcint, int dg) { ... }
Func defines a delegate with one argument and a non-void return. There
are lots of others like Action, Predicate, Comparator etc. which you
must either remember or look up every time you need a specific delegate
signature.
Ah, I didn't know you can't do something like Funcvoid, int. So there
could just be two things to remember: Func and Action.
Also you have FuncT1, T2, TResult, FuncT1, T2, T3, TResult, so it's
not just one argument.
I just tried casting one delegate type to another one with the same
signature and it doesn't work. So you are right, you need to remember
Predicate, Comparator, etc. :-(
Re: DIP6: Attributes
Steven Schveighoffer wrote:
On Tue, 04 Aug 2009 09:45:51 -0400, grauzone n...@example.net wrote:
Steven Schveighoffer wrote:
don't think it's worth adding them until we can have full reflection
capabilities so we can get at elements of code and therefore get the
annotations associated with it. I see much more usefulness for
annotations as reflection hints than as a replacement for keywords.
But we already have full reflection. It's called __traits. You can
build a serialization library or proper (user friendly?) reflection
on top of it.
I think you are the 1 millionth person to say it, and yet we still do
not have a user friendly reflection system. Why is that? You'd think
that if it could be done, somebody would have done it by now.
The reality is there's quite few of us. D is not in the stage where if
something could be done, somebody somewhere has done it or is working on it.
For example, I myself didn't know about __traits(allMembers) until it
was mentioned in this group. That's why I'd defined defineEnum, which
now is a relic replaced by the appropriate mechanism, contributed to by
Shin Fujishiro.
I know exactly how to go about a reflection system, but I simply haven't
gotten around to it. Here's an initial shot: starting with std.variant,
implement a function call:
class A { int foo() { return 42; } }
...
auto v = Variant(new A);
writeln(*v.call(foo).peek!int());
That should print 42. This is eminently doable with what we have now,
and could then be extended to multiple arguments etc. with the
appropriate amount of sweat.
The way to implement this would be to use __traits(allMembers) in the
templated constructor to store a hash that maps strings to delegates.
The delegates take no argument and return Variant. During construction
you can figure which members can be invoked with no arguments by using
e.g. is(typeof(...)) and initialize the hash appropriately. In the
call() function, you look up the string and fire the delegate.
Andrei
Re: DIP6: Attributes
On Tue, 04 Aug 2009 12:23:41 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Steven Schveighoffer wrote: On Tue, 04 Aug 2009 09:45:51 -0400, grauzone n...@example.net wrote: Steven Schveighoffer wrote: don't think it's worth adding them until we can have full reflection capabilities so we can get at elements of code and therefore get the annotations associated with it. I see much more usefulness for annotations as reflection hints than as a replacement for keywords. But we already have full reflection. It's called __traits. You can build a serialization library or proper (user friendly?) reflection on top of it. I think you are the 1 millionth person to say it, and yet we still do not have a user friendly reflection system. Why is that? You'd think that if it could be done, somebody would have done it by now. The reality is there's quite few of us. D is not in the stage where if something could be done, somebody somewhere has done it or is working on it. That's understandable, nobody can expect a language as young as D to have everything. But in reality, I think the *theory* that everything is there to build a reflection system is only proven when it actually happens. I'm sure when the enterprising person or persons go to develop it, they will find pieces missing from the static reflection system. So my point is that adding annotations before reflection works and is implemented makes little sense to me, because the usage of them will be crippled by the fact that reflection isn't complete. What I'd like to see is something like this possible: void foo (int timeout, string bar, float f = 4.0); void foo(int timeout); call!(foo)(timeout=5,bar=\hello\); Taking into account the default value of f, what the parameters are named, and which overload to call. I could certainly do it with C#. -Steve
Re: DIP6: Attributes
Steven Schveighoffer wrote: On Tue, 04 Aug 2009 12:23:41 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Steven Schveighoffer wrote: On Tue, 04 Aug 2009 09:45:51 -0400, grauzone n...@example.net wrote: Steven Schveighoffer wrote: don't think it's worth adding them until we can have full reflection capabilities so we can get at elements of code and therefore get the annotations associated with it. I see much more usefulness for annotations as reflection hints than as a replacement for keywords. But we already have full reflection. It's called __traits. You can build a serialization library or proper (user friendly?) reflection on top of it. I think you are the 1 millionth person to say it, and yet we still do not have a user friendly reflection system. Why is that? You'd think that if it could be done, somebody would have done it by now. The reality is there's quite few of us. D is not in the stage where if something could be done, somebody somewhere has done it or is working on it. That's understandable, nobody can expect a language as young as D to have everything. But in reality, I think the *theory* that everything is there to build a reflection system is only proven when it actually happens. I'm sure when the enterprising person or persons go to develop it, they will find pieces missing from the static reflection system. Exactly. I'm absolutely sure there are quite a few things needed here and there. I can assure you I'll push hard for those. So my point is that adding annotations before reflection works and is implemented makes little sense to me, because the usage of them will be crippled by the fact that reflection isn't complete. What I'd like to see is something like this possible: void foo (int timeout, string bar, float f = 4.0); void foo(int timeout); call!(foo)(timeout=5,bar=\hello\); Taking into account the default value of f, what the parameters are named, and which overload to call. I could certainly do it with C#. This is interesting. It means we'd need reflection for parameter names, which currently does not exist. Andrei
Re: DIP6: Attributes
Andrei Alexandrescu wrote: Steven Schveighoffer wrote: On Tue, 04 Aug 2009 12:23:41 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Steven Schveighoffer wrote: On Tue, 04 Aug 2009 09:45:51 -0400, grauzone n...@example.net wrote: Steven Schveighoffer wrote: don't think it's worth adding them until we can have full reflection capabilities so we can get at elements of code and therefore get the annotations associated with it. I see much more usefulness for annotations as reflection hints than as a replacement for keywords. But we already have full reflection. It's called __traits. You can build a serialization library or proper (user friendly?) reflection on top of it. I think you are the 1 millionth person to say it, and yet we still do not have a user friendly reflection system. Why is that? You'd think that if it could be done, somebody would have done it by now. The reality is there's quite few of us. D is not in the stage where if something could be done, somebody somewhere has done it or is working on it. That's understandable, nobody can expect a language as young as D to have everything. But in reality, I think the *theory* that everything is there to build a reflection system is only proven when it actually happens. I'm sure when the enterprising person or persons go to develop it, they will find pieces missing from the static reflection system. Exactly. I'm absolutely sure there are quite a few things needed here and there. I can assure you I'll push hard for those. So my point is that adding annotations before reflection works and is implemented makes little sense to me, because the usage of them will be crippled by the fact that reflection isn't complete. What I'd like to see is something like this possible: void foo (int timeout, string bar, float f = 4.0); void foo(int timeout); call!(foo)(timeout=5,bar=\hello\); Taking into account the default value of f, what the parameters are named, and which overload to call. I could certainly do it with C#. This is interesting. It means we'd need reflection for parameter names, which currently does not exist. Why do it with strings? Why not call!(foo)(5, hello) with varaidic args?
Re: DIP6: Attributes
On Tue, 04 Aug 2009 13:44:46 -0400, Ary Borenszweig a...@esperanto.org.ar wrote: Andrei Alexandrescu wrote: Steven Schveighoffer wrote: What I'd like to see is something like this possible: void foo (int timeout, string bar, float f = 4.0); void foo(int timeout); call!(foo)(timeout=5,bar=\hello\); Taking into account the default value of f, what the parameters are named, and which overload to call. I could certainly do it with C#. This is interesting. It means we'd need reflection for parameter names, which currently does not exist. Why do it with strings? Why not call!(foo)(5, hello) with varaidic args? Ok, say foo is: void foo(string bar, int timeout) -Steve
Re: DIP6: Attributes
Steven Schveighoffer wrote: On Tue, 04 Aug 2009 13:44:46 -0400, Ary Borenszweig a...@esperanto.org.ar wrote: Andrei Alexandrescu wrote: Steven Schveighoffer wrote: What I'd like to see is something like this possible: void foo (int timeout, string bar, float f = 4.0); void foo(int timeout); call!(foo)(timeout=5,bar=\hello\); Taking into account the default value of f, what the parameters are named, and which overload to call. I could certainly do it with C#. This is interesting. It means we'd need reflection for parameter names, which currently does not exist. Why do it with strings? Why not call!(foo)(5, hello) with varaidic args? Ok, say foo is: void foo(string bar, int timeout) What's the difference?
Re: DIP6: Attributes
On Tue, 04 Aug 2009 14:46:34 -0400, Ary Borenszweig a...@esperanto.org.ar wrote: Steven Schveighoffer wrote: On Tue, 04 Aug 2009 13:44:46 -0400, Ary Borenszweig a...@esperanto.org.ar wrote: Andrei Alexandrescu wrote: Steven Schveighoffer wrote: What I'd like to see is something like this possible: void foo (int timeout, string bar, float f = 4.0); void foo(int timeout); call!(foo)(timeout=5,bar=\hello\); Taking into account the default value of f, what the parameters are named, and which overload to call. I could certainly do it with C#. This is interesting. It means we'd need reflection for parameter names, which currently does not exist. Why do it with strings? Why not call!(foo)(5, hello) with varaidic args? Ok, say foo is: void foo(string bar, int timeout) What's the difference? The difference is, I'm saying I want to call foo with parameters identified by parameter name, not parameter order. -Steve
Re: DIP6: Attributes
Andrei Alexandrescu schrieb: Ary Borenszweig wrote: call!(foo)(5, hello) with varaidic args? Well some don't like to need to remember the order of arguments. Andrei Assigning the argument by name instead of order has two other benefits, i can think of... 1. on the call side, it is documented for what the given values are used. 2. it may be possible to let all parameters have default values and for example just give a value for the last parameter. This is not possible with just the parameter order.
Re: DIP6: Attributes
Andrei Alexandrescu wrote:
Ary Borenszweig wrote:
Andrei Alexandrescu wrote:
Steven Schveighoffer wrote:
On Tue, 04 Aug 2009 12:23:41 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Steven Schveighoffer wrote:
On Tue, 04 Aug 2009 09:45:51 -0400, grauzone n...@example.net
wrote:
Steven Schveighoffer wrote:
don't think it's worth adding them until we can have full
reflection capabilities so we can get at elements of code and
therefore get the annotations associated with it. I see much
more usefulness for annotations as reflection hints than as a
replacement for keywords.
But we already have full reflection. It's called __traits. You
can build a serialization library or proper (user friendly?)
reflection on top of it.
I think you are the 1 millionth person to say it, and yet we
still do not have a user friendly reflection system. Why is
that? You'd think that if it could be done, somebody would have
done it by now.
The reality is there's quite few of us. D is not in the stage where
if something could be done, somebody somewhere has done it or is
working on it.
That's understandable, nobody can expect a language as young as D to
have everything.
But in reality, I think the *theory* that everything is there to
build a reflection system is only proven when it actually happens.
I'm sure when the enterprising person or persons go to develop it,
they will find pieces missing from the static reflection system.
Exactly. I'm absolutely sure there are quite a few things needed here
and there. I can assure you I'll push hard for those.
So my point is that adding annotations before reflection works and
is implemented makes little sense to me, because the usage of them
will be crippled by the fact that reflection isn't complete.
What I'd like to see is something like this possible:
void foo (int timeout, string bar, float f = 4.0);
void foo(int timeout);
call!(foo)(timeout=5,bar=\hello\);
Taking into account the default value of f, what the parameters are
named, and which overload to call. I could certainly do it with C#.
This is interesting. It means we'd need reflection for parameter
names, which currently does not exist.
Why do it with strings? Why not
call!(foo)(5, hello)
with varaidic args?
Well some don't like to need to remember the order of arguments.
But that's a way totally different thing discussed here.
First you need to introduce argument names when invoking a function.
void foo(int timeout, string bar) {
..
}
Can be used as:
foo(timeout=5, bar=100)
(with some other syntax, of course)
Once you have that, you could do:
call!(foo)(timeout=5, bar=100)
Voilà!
Re: DIP6: Attributes
Ary Borenszweig wrote: Andrei Alexandrescu wrote: Ary Borenszweig wrote: Andrei Alexandrescu wrote: Steven Schveighoffer wrote: On Tue, 04 Aug 2009 12:23:41 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Steven Schveighoffer wrote: On Tue, 04 Aug 2009 09:45:51 -0400, grauzone n...@example.net wrote: Steven Schveighoffer wrote: don't think it's worth adding them until we can have full reflection capabilities so we can get at elements of code and therefore get the annotations associated with it. I see much more usefulness for annotations as reflection hints than as a replacement for keywords. But we already have full reflection. It's called __traits. You can build a serialization library or proper (user friendly?) reflection on top of it. I think you are the 1 millionth person to say it, and yet we still do not have a user friendly reflection system. Why is that? You'd think that if it could be done, somebody would have done it by now. The reality is there's quite few of us. D is not in the stage where if something could be done, somebody somewhere has done it or is working on it. That's understandable, nobody can expect a language as young as D to have everything. But in reality, I think the *theory* that everything is there to build a reflection system is only proven when it actually happens. I'm sure when the enterprising person or persons go to develop it, they will find pieces missing from the static reflection system. Exactly. I'm absolutely sure there are quite a few things needed here and there. I can assure you I'll push hard for those. So my point is that adding annotations before reflection works and is implemented makes little sense to me, because the usage of them will be crippled by the fact that reflection isn't complete. What I'd like to see is something like this possible: void foo (int timeout, string bar, float f = 4.0); void foo(int timeout); call!(foo)(timeout=5,bar=\hello\); Taking into account the default value of f, what the parameters are named, and which overload to call. I could certainly do it with C#. This is interesting. It means we'd need reflection for parameter names, which currently does not exist. Why do it with strings? Why not call!(foo)(5, hello) with varaidic args? Well some don't like to need to remember the order of arguments. But that's a way totally different thing discussed here. Sorry, not totally different. What I'm saying is: one thing at a time.
Re: DIP6: Attributes
On Tue, 04 Aug 2009 15:56:16 -0400, Ary Borenszweig a...@esperanto.org.ar
wrote:
Andrei Alexandrescu wrote:
Well some don't like to need to remember the order of arguments.
But that's a way totally different thing discussed here.
First you need to introduce argument names when invoking a function.
void foo(int timeout, string bar) {
..
}
Can be used as:
foo(timeout=5, bar=100)
(with some other syntax, of course)
Once you have that, you could do:
call!(foo)(timeout=5, bar=100)
Voilà!
It could also be accomplished via a fully implemented reflection library,
which is my side topic for this thread branch :P
For instance you could do this exact thing in C#, even though C# doesn't
support named parameters.
-Steve
Re: DIP6: Attributes
Steven Schveighoffer wrote:
On Tue, 04 Aug 2009 15:56:16 -0400, Ary Borenszweig
a...@esperanto.org.ar wrote:
Andrei Alexandrescu wrote:
Well some don't like to need to remember the order of arguments.
But that's a way totally different thing discussed here.
First you need to introduce argument names when invoking a function.
void foo(int timeout, string bar) {
..
}
Can be used as:
foo(timeout=5, bar=100)
(with some other syntax, of course)
Once you have that, you could do:
call!(foo)(timeout=5, bar=100)
Voilà!
It could also be accomplished via a fully implemented reflection
library, which is my side topic for this thread branch :P
For instance you could do this exact thing in C#, even though C# doesn't
support named parameters.
Aaah... I see now. :)
Re: DIP6: Attributes
Steven Schveighoffer wrote: On Tue, 04 Aug 2009 15:56:16 -0400, Ary Borenszweig a...@esperanto.org.ar wrote: foo(timeout=5, bar=100) It could also be accomplished via a fully implemented reflection library, which is my side topic for this thread branch :P No. The names of positional arguments are an implementation detail, and should not be exposed via reflection. Named arguments are different from positional arguments and require separate language support. Consider the ambiguity caused by function overloading: void f(int x, string y); void f(string y, int x); f(x = 1, y = ); Consider the implications of function pointers: void f(int x, int y); void g(int y, int x); (cond ? f : g)(x = 1, y = 2); -- Rainer Deyke - rain...@eldwood.com
Re: DIP6: Attributes
Steven Schveighoffer wrote: For instance you could do this exact thing in C#, even though C# doesn't support named parameters. But they're coming: http://msdn.microsoft.com/en-us/library/dd264739(VS.100).aspx
Re: DIP6: Attributes
On 8/4/09 18:55, Steven Schveighoffer wrote: On Tue, 04 Aug 2009 12:23:41 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Steven Schveighoffer wrote: On Tue, 04 Aug 2009 09:45:51 -0400, grauzone n...@example.net wrote: Steven Schveighoffer wrote: don't think it's worth adding them until we can have full reflection capabilities so we can get at elements of code and therefore get the annotations associated with it. I see much more usefulness for annotations as reflection hints than as a replacement for keywords. But we already have full reflection. It's called __traits. You can build a serialization library or proper (user friendly?) reflection on top of it. I think you are the 1 millionth person to say it, and yet we still do not have a user friendly reflection system. Why is that? You'd think that if it could be done, somebody would have done it by now. The reality is there's quite few of us. D is not in the stage where if something could be done, somebody somewhere has done it or is working on it. That's understandable, nobody can expect a language as young as D to have everything. But in reality, I think the *theory* that everything is there to build a reflection system is only proven when it actually happens. I'm sure when the enterprising person or persons go to develop it, they will find pieces missing from the static reflection system. So my point is that adding annotations before reflection works and is implemented makes little sense to me, because the usage of them will be crippled by the fact that reflection isn't complete. What I'd like to see is something like this possible: void foo (int timeout, string bar, float f = 4.0); void foo(int timeout); call!(foo)(timeout=5,bar=\hello\); Taking into account the default value of f, what the parameters are named, and which overload to call. I could certainly do it with C#. -Steve You mean like this: http://tango.pastebin.com/m129241b0 ? /Jacob Carlborg
Re: DIP6: Attributes
On 8/5/09 00:22, Jacob Carlborg wrote: On 8/4/09 18:55, Steven Schveighoffer wrote: On Tue, 04 Aug 2009 12:23:41 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Steven Schveighoffer wrote: On Tue, 04 Aug 2009 09:45:51 -0400, grauzone n...@example.net wrote: Steven Schveighoffer wrote: don't think it's worth adding them until we can have full reflection capabilities so we can get at elements of code and therefore get the annotations associated with it. I see much more usefulness for annotations as reflection hints than as a replacement for keywords. But we already have full reflection. It's called __traits. You can build a serialization library or proper (user friendly?) reflection on top of it. I think you are the 1 millionth person to say it, and yet we still do not have a user friendly reflection system. Why is that? You'd think that if it could be done, somebody would have done it by now. The reality is there's quite few of us. D is not in the stage where if something could be done, somebody somewhere has done it or is working on it. That's understandable, nobody can expect a language as young as D to have everything. But in reality, I think the *theory* that everything is there to build a reflection system is only proven when it actually happens. I'm sure when the enterprising person or persons go to develop it, they will find pieces missing from the static reflection system. So my point is that adding annotations before reflection works and is implemented makes little sense to me, because the usage of them will be crippled by the fact that reflection isn't complete. What I'd like to see is something like this possible: void foo (int timeout, string bar, float f = 4.0); void foo(int timeout); call!(foo)(timeout=5,bar=\hello\); Taking into account the default value of f, what the parameters are named, and which overload to call. I could certainly do it with C#. -Steve You mean like this: http://tango.pastebin.com/m129241b0 ? /Jacob Carlborg Forgot to say: this works in D1 with dmd, gdc and ldc. /Jacob Carlborg
Re: DIP6: Attributes
On Tue, 04 Aug 2009 17:20:53 -0400, Rainer Deyke rain...@eldwood.com wrote: Steven Schveighoffer wrote: On Tue, 04 Aug 2009 15:56:16 -0400, Ary Borenszweig a...@esperanto.org.ar wrote: foo(timeout=5, bar=100) It could also be accomplished via a fully implemented reflection library, which is my side topic for this thread branch :P No. The names of positional arguments are an implementation detail, and should not be exposed via reflection. Named arguments are different from positional arguments and require separate language support. It works. See http://msdn.microsoft.com/en-us/library/system.reflection.parameterinfo.name.aspx Consider the ambiguity caused by function overloading: void f(int x, string y); void f(string y, int x); f(x = 1, y = ); That is a case where the proposed function would throw an exception. Consider the implications of function pointers: void f(int x, int y); void g(int y, int x); (cond ? f : g)(x = 1, y = 2); I don't see what this has to do with reflection... -Steve
Re: DIP6: Attributes
Frank Benoit wrote: Andrei Alexandrescu schrieb: Ary Borenszweig wrote: call!(foo)(5, hello) with varaidic args? Well some don't like to need to remember the order of arguments. Andrei Assigning the argument by name instead of order has two other benefits, i can think of... 1. on the call side, it is documented for what the given values are used. 2. it may be possible to let all parameters have default values and for example just give a value for the last parameter. This is not possible with just the parameter order. But these aren't issues with reflection. These are just the same function calling rules applied elsewhere in the language: 1) If you want to call a function: you must know its name. 2) If you want to pass parameters: you must know the correct order. I can't imagine a circumstance where someone uses reflection to call a function and knows how to create the correct set of arguments, but doesn't know what order to put them in. --benji
Re: DIP6: Attributes
grauzone Wrote:
Ary Borenszweig wrote:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6
The next step would be to introduce user defined annotations. I propose
this:
//--
//declaring a user defined annotation type
@annotation
struct MyAnnotation {
int x;
char[] y;
SubAnnotation sub;
}
struct SubAnnotation {
int x;
}
//use the annotation on SomeType
@MyAnnotation(123, 456, SubAnnotation(789))
class SomeType {
}
//reading user defined annotations
void foo() {
foreach (t; __traits(getAnnotations, SomeType) {
//t is a value of the annotation type
//SomeType is only annotated with MyAnnotation
static assert(is(typeof(t) == MyAnnotation));
//can read out the annotation values
assert(t.y == 456);
}
}
//--
Using @annotation on a type introduces the type name into the annotation
namespace. This means the type can be used as annotation on other types.
The annotation declaration is parsed as if you'd define a compile time
constant using the expression following the @, e.g. const c =
MyAnnotation(123, [...]);
This means the @ is actually just followed by an expression, that
actually uses opCall() (in this case opCall is autogenerated by the
compiler). The expression is evaluated using CTFE.
Note that compile time annotations (like @override, @property) still can
collide with user defined types, but only if those types are marked by
@annotation. (Actually, compile time annotations can be normal types
declared in object.d.)
__traits(getAnnotations, SomeType) returns a tuple containing the values
of all annotations applied to a type. In other words, the result of the
CTFE execution of each annotation.
Any thoughts?
PS: I wouldn't use annotations for all attribute keywords (like
override, final, pure, ...). Some keywords should be left as they are.
Only seldom used and/or new keywords should be introduced as annotations
(for example deprecated or __gshared [there's a type on the DIP page btw.]).
PPS: shoudl annotations follow the normal D attribute syntax? E.g. allow
this:
@someannotation declaration;
@someannotation {
declaration1;
declaration2;
}
@someannotation:
declaration1;
declaration2;
this is a good start but as already noted by others, you can't specify types
with structs. we also can't use type tuples cause of the auto flatten behavior.
the type tuple issue needs to be fixed and perhaps we can introduce type
variables. something like:
type t = int;
other thoughts on the subject:
the user should be able to specify the lifetime of the annotations,
compile-time vs. run-time.
Re: DIP6: Attributes
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?
Re: DIP6: Attributes
Ary Borenszweig wrote: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6 I like the idea of attributes having names that can never be identifiers, since adding new attributes will then, as you point out, never break existing code. But won't we lose this benefit if we later allow user-defined annotations? -Lars
Re: DIP6: Attributes
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?
Re: DIP6: Attributes
yigal chripun wrote: this is a good start but as already noted by others, you can't specify types with structs. we also can't use type tuples cause of the auto flatten behavior. And why can't we use structs? Unless I've missed something, it wasn't explained in this thread.
Re: DIP6: Attributes
Lars T. Kyllingstad escribió: Ary Borenszweig wrote: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6 I like the idea of attributes having names that can never be identifiers, since adding new attributes will then, as you point out, never break existing code. But won't we lose this benefit if we later allow user-defined annotations? Kind of, but not totally. If you allow user-defined annotations, they need to be placed in a module, so they have a fully qualified name. You could have an foo.bar.align annotation (supposing align was already an annotation) and do: @foo.bar.align int x; The compiler-instrinsic annotations would be defined in module object or something like that. That way you can disambiguate annotations with same names.
Re: DIP6: Attributes
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? Lack of power. People today want powerful language. With attributes you can arbitrarily extend metadata, see AttributeTargets enumeration http://msdn.microsoft.com/en-us/library/system.attributetargets.aspx
Re: DIP6: Attributes
Ary Borenszweig Wrote: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6 VB uses angle brackets to delimit attributes. They usually don't repeat, only chain... unless you want to put them in strange places...
Re: DIP6: Attributes
grauzone Wrote: yigal chripun wrote: this is a good start but as already noted by others, you can't specify types with structs. we also can't use type tuples cause of the auto flatten behavior. And why can't we use structs? Unless I've missed something, it wasn't explained in this thread. inheritance?
Re: DIP6: Attributes
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.
Re: DIP6: Attributes
Don Wrote: 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. Here you considered functionality of only one attribute, XmlIgnoreAttribute. XML serialization in .net framework uses 17 attributes. For example you can serialize a field as an XML element or an XML attribute, how do you plan to handle this?
Re: DIP6: Attributes
On Mon, 03 Aug 2009 09:26:21 -0400, Don nos...@nospam.com wrote: 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. Typically, items excluded from serialization are left uninitialized, or initialized via default initializers. These types of items usually don't make sense to restore anyways, like file handles, or cached lookup data. 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. Annotations have more usages than just how to serialize. Some uses I've seen in C#: * hints to an IDE about a GUI component (what it does, what properties to allow setting via the visual builder) * hints to the debugger about when to skip debugging certain functions (to avoid stepping into mundane crap such as property getters). * hints to another program about which classes would be interesting when dynamically loading a library On that last one, I wrote an editor that would create xml files indicating how to call constructors of certain types in an executable. I tagged the types with attributes that described what they do, and how to display them in the editor (for example, is an integer a bitmask? if so, display a set of checkboxes with these names). Then when I would add classes to the executable, I did not have to update the editor. Annotations are useful in many ways, but without full reflection capabilities, they are restricted to things that can read them via source code, and so they are no better than comments. -Steve
Re: DIP6: Attributes
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]
Re: DIP6: Attributes
Ary Borenszweig, el 3 de agosto a las 11:14 me escribiste: 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] It's easy to support some sort of primitive-explicit AOP[1] too. It's very used in Python. For example I've implemented the synchronized attribute in Python using decorators (annotations). [1] http://en.wikipedia.org/wiki/Aspect-oriented_programming -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) I love las minifaldas on Esmeralda And the sexy porteños trying to pick up the Argenteenagers. How nice, the Argenteenagers Tomando sol in the primavera de Buenos Aires...
Re: DIP6: Attributes
I'd rather see this put off until we have macros; then steal the syntax to mean the same thing it does in Python.
Re: DIP6: Attributes
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?
struct Foo
{
int serialise_me, dont_serialise_me, or_me;
alias Tuple!(dont_serialise_me, or_me) IgnoreForSerialisation;
}
Or, if you'd rather have a less hacky interface:
struct Foo
{
int serialise_me, dont_serialise_me, or_me;
mixin IgnoreForSerialisation!(dont_serialise_me, or_me);
}
Re: DIP6: Attributes
Steven Schveighoffer wrote: On Mon, 03 Aug 2009 09:26:21 -0400, Don nos...@nospam.com wrote: 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? [snip] Annotations are useful in many ways, but without full reflection capabilities, they are restricted to things that can read them via source code, and so they are no better than comments. This is a very, very important observation, and I think it belongs in the DIP. It means that it probably doesn't make much sense to implement annotations without also having an intention to implement full-blown reflection.
Re: DIP6: Attributes
Daniel Keep wrote:
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?
struct Foo
{
int serialise_me, dont_serialise_me, or_me;
alias Tuple!(dont_serialise_me, or_me) IgnoreForSerialisation;
}
Or, if you'd rather have a less hacky interface:
struct Foo
{
int serialise_me, dont_serialise_me, or_me;
mixin IgnoreForSerialisation!(dont_serialise_me, or_me);
}
I can imagine this also:
struct Foo {
char[] one;
int two;
float three;
mixin SerializeAsXmlElement!(one, desiredNameForOne, two,
desiredNameForTwo);
mixin SerializeAsXmlAttribute!(three, desiredNameForThree);
}
That looks great. And as your struct grows, you have to scroll down to
see how an element is serialized. And if you want to change how an
element is serialized you scroll down and move two strings from one
point to another. I also wonder *how* is that mixed template
implemented, it probably adds some fields or things to that struct.
How about this:
struct Foo {
@XmlElement(desiredNameForOne);
char[] one;
@XmlElement(desiredNameForTwo);
int two;
@XmlAttribute(desiredNameForThree);
float three;
}
Which one looks nicer and more understandable to you? How do you change
a property to be serialized as an element to an attribute? You just
change XmlElement to XmlAttribute and that's it.
Your approach also is no DRY: you have to name the fields again. It
might throw awful compiler errors for template code when you mistype
something. If you rename a field you must also remember to rename the
serialization mixin.
Re: DIP6: Attributes
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? Anyway, I'll write some more about attributes in the abstract or rationale.
Re: DIP6: Attributes
Kagamin wrote: grauzone Wrote: yigal chripun wrote: this is a good start but as already noted by others, you can't specify types with structs. we also can't use type tuples cause of the auto flatten behavior. And why can't we use structs? Unless I've missed something, it wasn't explained in this thread. inheritance? You want to inherit annotations? What for?
Re: DIP6: Attributes
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
Re: DIP6: Attributes
On Tue, 04 Aug 2009 01:30:29 +1000, Daniel Keep
daniel.keep.li...@gmail.com wrote:
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?
struct Foo
{
int serialise_me, dont_serialise_me, or_me;
alias Tuple!(dont_serialise_me, or_me) IgnoreForSerialisation;
}
Or, if you'd rather have a less hacky interface:
struct Foo
{
int serialise_me, dont_serialise_me, or_me;
mixin IgnoreForSerialisation!(dont_serialise_me, or_me);
}
You can even use a mixin per member:
struct Foo
{
mixin Persistent!(field, field-as-it-is-named-in-db);
int field;
mixin Persistent!(field2);
mixin Serializable!(field2);
int field2;
}
It would be nice (and that is unlikely to happen) if the compiler
could rewrite
struct Foo
{
@Persistent(db_field)
@Serializable
int field;
}
to
struct Foo
{
int field;
mixin Persistent!(field, db_field);
mixin Serializable!(field);
}
Re: DIP6: Attributes
Max Samukha wrote:
It would be nice (and that is unlikely to happen) if the compiler
could rewrite
struct Foo
{
@Persistent(db_field)
@Serializable
int field;
}
to
struct Foo
{
int field;
mixin Persistent!(field, db_field);
mixin Serializable!(field);
}
It'd be even nicer if it wouldn't require ridiculous hacks from you to
read out the annotation data again.
E.g. right now, that Serializable mixin would define something like
const bool field_serializeable = true;, and you'd need to use CTFE
string concatenation (better hope the compiler's GC is enabled) and is()
to define/read the data. Very clumsy and hackish, although it would work.
For me, making these things simpler is the whole point of annotations.
Looks like we have three basic things that annotations could be used for:
1. alternative namespace for keywords
2. associate arbitrary, user defined metadata with types and fields
3. macro madness (using the approach found in Python)
Re: DIP6: Attributes
Ary Borenszweig wrote:
Daniel Keep wrote:
grauzone wrote:
...
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?
struct Foo
{
int serialise_me, dont_serialise_me, or_me;
alias Tuple!(dont_serialise_me, or_me) IgnoreForSerialisation;
}
Or, if you'd rather have a less hacky interface:
struct Foo
{
int serialise_me, dont_serialise_me, or_me;
mixin IgnoreForSerialisation!(dont_serialise_me, or_me);
}
...
That looks great. And as your struct grows, you have to scroll down to
see how an element is serialized. And if you want to change how an
element is serialized you scroll down and move two strings from one
point to another. I also wonder *how* is that mixed template
implemented, it probably adds some fields or things to that struct.
How would you do this in D?
I was answering the question.
How about this:
struct Foo {
@XmlElement(desiredNameForOne);
char[] one;
@XmlElement(desiredNameForTwo);
int two;
@XmlAttribute(desiredNameForThree);
float three;
}
Which one looks nicer and more understandable to you? How do you change
a property to be serialized as an element to an attribute? You just
change XmlElement to XmlAttribute and that's it.
Which one works right now and doesn't require you first spend at least a
year convincing Walter that it's useful, then convincing him it's
necessary, followed by six months of continuous bike-shedding by the
community before Walter gives up and implements something that somehow
manages to piss off everyone who was arguing for it, largely because it
wasn't the exact syntax they wanted?
Which one have I been successfully using in a project of mine for over
two and a half years now thanks to it also working in crusty old D1?
Who's the one with a working struct-xml parser template based on it?
Your approach also is no DRY: you have to name the fields again. It
might throw awful compiler errors for template code when you mistype
something. If you rename a field you must also remember to rename the
serialization mixin.
It's odd; I can't find the part of my post where I said this was perfect
and the ideal solution! My newsreader must be truncating my messages...
Re: DIP6: Attributes
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.
Re: DIP6: Attributes
On Mon, 03 Aug 2009 19:53:21 +0400, Steven Schveighoffer schvei...@yahoo.com 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. 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 Compiler could embed some kind of a hash from attributes in a mangled name.
Re: DIP6: Attributes
grauzone Wrote: yigal chripun wrote: this is a good start but as already noted by others, you can't specify types with structs. we also can't use type tuples cause of the auto flatten behavior. And why can't we use structs? Unless I've missed something, it wasn't explained in this thread. how can you pass types as arguments to your annotation if that annotation is a struct? for instance, what would be the struct for: @my_annotation(int, 4)
Re: DIP6: Attributes
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? Keyword proliferation for a zillion tiny features? Annotations would help with that very nicely. --benji
Re: DIP6: Attributes
Steven Schveighoffer wrote:
Annotations have more usages than just how to serialize. Some uses I've
seen in C#:
* hints to an IDE about a GUI component (what it does, what properties
to allow setting via the visual builder)
* hints to the debugger about when to skip debugging certain functions
(to avoid stepping into mundane crap such as property getters).
* hints to another program about which classes would be interesting when
dynamically loading a library
In Actionscript (and the Flex framework), one very handy use of
annotations is to mark a public field as bindable.
class MyClass {
[Bindable]
public var MyField:int = 0;
}
In this example, whenever the MyField value is updated, a
property-change event will be send to all listeners. The XML-based Flex
framework uses those annotations to create (unidirectional or
bidirectional) bindings between variables.
Window
HSlider id=mySlider/
Image
source=...
width={mySlider.value}
height={mySlider.value}
/
/Window
This creates a window with two controls, a horizontal numeric slider and
an image. Whenever the user drags the slider control, the width and
height of the image automatically update themselves.
The reason this works is that the value field of the HSlider
object is marked with the Bindable annotation. The compiler silently
converts the field into a property getter/setter pair, and the setter
sends out property-change events whenever called.
(Good thing Actionscript properties exist, with a syntax identical to
normal fields, or else the automatic data binding wouldn't work!)
The cool thing that makes this work is that the compiler can perform
code transformation based on the existence of various annotations.
--benji
Re: DIP6: Attributes
On Sat, 01 Aug 2009 15:24:26 -0700, Robert Fraser fraseroftheni...@gmail.com wrote: Ary Borenszweig wrote: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6 I think annotations are a good idea, but turning keywords already in the language into annotations seems kinda pointless would kill backwards compatibility. In C#/Java some things are modifiers while others are annotations -- and with good reason. IMO, the focus of annotations should be mostly on things _external_ to the compiler. So, serializability, thread safety, etc. Really, I think annotations should be for compile-time reflection (so like someone else said __traits(annotations, symbol) should return a tuple of annotation structs. Please not a tuple of structs but a tuple of tuples. One should be able to specify types and aliases as annotation parameters.
Re: DIP6: Attributes
Ary Borenszweig wrote: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6 I like this. Metadata is a very useful thing.
Re: DIP guidelines [was: DIP6: Attributes]
Ary Borenszweig, el 2 de agosto a las 00:07 me escribiste: Leandro Lucarella escribió: Ary Borenszweig, el 1 de agosto a las 16:29 me escribiste: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6 Please, try to post at least the abstract of the DIP with the link, so people can easily know what is it about =) And when writing a DIP, try to make the abstract a little more descriptive. From an abstract you should be able to tell what the DIP is about (in this case explain what an annotation is at least). A oneliner is not good enough, that's just a title, not an abstract. If it's too hard to explain, try to provide a link to somewhere else where the terms are described. The rationale can be a little more descriptive too. What are the advantages of removing keywords for example? Use NG posts links if you have some problems documented there, for example. Try not to explain your opinion in DIPs. They are not NG posts, they should provide facts and be as objective as possible. Even when that's pretty hard, saying I prefer Java's one because ... is excessively subjective. Avoid doing that. You can express the same by saying something like Java syntax has the advantage of ... for example. A section called Other thoughts is not very serious either. If you are not yet convinced about something in the DIP, post it in the announcement post in the NG so it can be discussed and added later to the DIP when the idea is in better shape. Please, don't take this personally, I just want DIPs to be high quality, otherwise they will never be taken seriously. =) I've added this information in a Recommendations subsection to the DIP1, see: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP1#Recommendations I'll address the DIP itself in another post ;) Hola Leandro, I've updated the DIP page with your recommendations. I agree with all of them. Thanks! -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) Somos testigos de Jaimito, venimos a traer la salvación, el mundo va a desaparecer, somos testigos de Jaimito!. Nos enyoguizamos... Así que somos testigos? Te dejo el culo hecho un vino, y la conch'itumá, y la conch'itumá! -- Sidharta Kiwi
Re: DIP6: Attributes
On Sun, 02 Aug 2009 07:54:49 -0700, Robert Fraser
fraseroftheni...@gmail.com wrote:
Max Samukha wrote:
On Sat, 01 Aug 2009 15:24:26 -0700, Robert Fraser
fraseroftheni...@gmail.com wrote:
Ary Borenszweig wrote:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6
I think annotations are a good idea, but turning keywords already in the
language into annotations seems kinda pointless would kill backwards
compatibility. In C#/Java some things are modifiers while others are
annotations -- and with good reason.
IMO, the focus of annotations should be mostly on things _external_ to
the compiler. So, serializability, thread safety, etc. Really, I think
annotations should be for compile-time reflection (so like someone else
said __traits(annotations, symbol) should return a tuple of annotation
structs.
Please not a tuple of structs but a tuple of tuples. One should be
able to specify types and aliases as annotation parameters.
I wish that's work, but Tuples flatten themselves.
Yes, but we can define a non-flattening tuple:
template CannedTuple(A...)
{
alias A tuple;
}
Then we can have tuples of tuples:
alias Tuple!(CannedTuple!(...), CannedTuple!(...), ...) annotations;
// I guess, the first element should be the annotation name?
enum annotationName = annotations[0].tuple[0];
We already can emulate custom attributes with mixins, though this
requires template trickery that sometimes is overwhelming. So some
syntax sugar would be welcome.
Re: DIP6: Attributes
Ary Borenszweig wrote:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6
The next step would be to introduce user defined annotations. I propose
this:
//--
//declaring a user defined annotation type
@annotation
struct MyAnnotation {
int x;
char[] y;
SubAnnotation sub;
}
struct SubAnnotation {
int x;
}
//use the annotation on SomeType
@MyAnnotation(123, 456, SubAnnotation(789))
class SomeType {
}
//reading user defined annotations
void foo() {
foreach (t; __traits(getAnnotations, SomeType) {
//t is a value of the annotation type
//SomeType is only annotated with MyAnnotation
static assert(is(typeof(t) == MyAnnotation));
//can read out the annotation values
assert(t.y == 456);
}
}
//--
Using @annotation on a type introduces the type name into the annotation
namespace. This means the type can be used as annotation on other types.
The annotation declaration is parsed as if you'd define a compile time
constant using the expression following the @, e.g. const c =
MyAnnotation(123, [...]);
This means the @ is actually just followed by an expression, that
actually uses opCall() (in this case opCall is autogenerated by the
compiler). The expression is evaluated using CTFE.
Note that compile time annotations (like @override, @property) still can
collide with user defined types, but only if those types are marked by
@annotation. (Actually, compile time annotations can be normal types
declared in object.d.)
__traits(getAnnotations, SomeType) returns a tuple containing the values
of all annotations applied to a type. In other words, the result of the
CTFE execution of each annotation.
Any thoughts?
PS: I wouldn't use annotations for all attribute keywords (like
override, final, pure, ...). Some keywords should be left as they are.
Only seldom used and/or new keywords should be introduced as annotations
(for example deprecated or __gshared [there's a type on the DIP page btw.]).
PPS: shoudl annotations follow the normal D attribute syntax? E.g. allow
this:
@someannotation declaration;
@someannotation {
declaration1;
declaration2;
}
@someannotation:
declaration1;
declaration2;
DIP6: Attributes
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6
Re: DIP6: Attributes
Ary Borenszweig escribió: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6 Ouch. I meant: DIP6: Annotations.
Re: DIP6: Attributes
Adam D. Ruppe escribió: On Sat, Aug 01, 2009 at 04:29:28PM -0300, Ary Borenszweig wrote: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6 What's the difference between this and a keyword? It seems to be a keyword with a different name. A keyword means changing the lexer, the parser and the semantic analysis. Annotations means only changing the semantic analysis (ok, changing the lexer and parser also, but just the first time to implement annotations). And if the first stage is implemented, what you describe below could also be implemented. As the DIP says, the advantage is also reducing the huge amount of keywords that exist now in the language. For this annotation thing to be really useful, I'd think it should be well, dynamic for lack of a better word. You can just list them on an item, then inspect them later in templates: @magic int a; [...] auto annotations = __traits(annotations, a); assert(annotations[0] == magic); // now you can do whatever with this I wished I had something like this before, but I forgot why But if you aren't proposing something like that being possible, then what's the point of the @ to a keyword? It doesn't seem to be any different. I could have included that in the DIP. But you have to start with small things, simple things, and evolve from that point. The DIP is just about how to start introducing annotations in the language with minimal changes to what exists now.
Re: DIP6: Attributes
Adam D. Ruppe destructiona...@gmail.com wrote in message news:mailman.258.1249155638.14071.digitalmar...@puremagic.com... On Sat, Aug 01, 2009 at 04:29:28PM -0300, Ary Borenszweig wrote: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6 What's the difference between this and a keyword? It seems to be a keyword with a different name. It doesn't reduce the pool of available identifier names since user-created identifiers can't contain @ anyway (at least I don't think they can). Plus, (down the road, with the reflection stuff you mentioned) it would be possible to create new annotations purely in a library without requiring changes to the language or compiler.
Re: DIP6: Attributes
On Sat, 01 Aug 2009 16:29:28 -0300 Ary Borenszweig a...@esperanto.org.ar wrote: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6 Are pragmas not already here for this?
Re: DIP6: Attributes
Tim Matthews wrote: On Sat, 01 Aug 2009 16:29:28 -0300 Ary Borenszweig a...@esperanto.org.ar wrote: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6 Are pragmas not already here for this? Nope, they're for compiler-specific extensions
Re: DIP6: Attributes
Robert Fraser wrote: Ary Borenszweig wrote: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6 I think annotations are a good idea, but turning keywords already in the language into annotations seems kinda pointless would kill backwards compatibility. In C#/Java some things are modifiers while others are annotations -- and with good reason. IMO, the focus of annotations should be mostly on things _external_ to the compiler. So, serializability, thread safety, etc. Really, I think annotations should be for compile-time reflection (so like someone else said __traits(annotations, symbol) should return a tuple of annotation structs. Seconded. Annotations sound like a useful feature especially if they can be created and manipulated by the programmer, which would require syntactic distinction. I never did much care for java's annotation syntax, but I do think turning most if not all of the keywords mentioned into annotations is a good idea, at least behind the scenes. Off the top of my head, it could solve the function - delegate ref parameter problem.
DIP guidelines [was: DIP6: Attributes]
Ary Borenszweig, el 1 de agosto a las 16:29 me escribiste: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6 Please, try to post at least the abstract of the DIP with the link, so people can easily know what is it about =) And when writing a DIP, try to make the abstract a little more descriptive. From an abstract you should be able to tell what the DIP is about (in this case explain what an annotation is at least). A oneliner is not good enough, that's just a title, not an abstract. If it's too hard to explain, try to provide a link to somewhere else where the terms are described. The rationale can be a little more descriptive too. What are the advantages of removing keywords for example? Use NG posts links if you have some problems documented there, for example. Try not to explain your opinion in DIPs. They are not NG posts, they should provide facts and be as objective as possible. Even when that's pretty hard, saying I prefer Java's one because ... is excessively subjective. Avoid doing that. You can express the same by saying something like Java syntax has the advantage of ... for example. A section called Other thoughts is not very serious either. If you are not yet convinced about something in the DIP, post it in the announcement post in the NG so it can be discussed and added later to the DIP when the idea is in better shape. Please, don't take this personally, I just want DIPs to be high quality, otherwise they will never be taken seriously. =) I've added this information in a Recommendations subsection to the DIP1, see: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP1#Recommendations I'll address the DIP itself in another post ;) -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) HOMBRE DESNUDO AMENAZA A LOS VECINOS CON UNA KATANA DESDE SU BALCON -- Crónica TV
Re: DIP6: Attributes
Ary Borenszweig, el 1 de agosto a las 16:29 me escribiste:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6
I really think that D should support some kind of annotations. I think
it's a good idea to add them in stages. I could add that in the first
stage, old-style attributes/whatever (override, deprecated, etc.) should
be accepted too (i.e. without the leading @). Then people complaining
about backward compatibility can be happy (me included; hey! I'll add them
to D1.1 too! ;). New syntax can make use of annotations though (hello
properties!).
I think annotations in D can reach their peak of utility when AST macros
get implemented. I think it would be great being able to register
annotation handlers to the compiler to do arbitrary transformations to the
code. You could even move a big part of the compiler implementation to
library code using annotations and AST macros. But this have to come in
other stages for sure.
I think changing the FE to allow annotation syntax wouldn't be very hard
(I'm guessing, I never hacked the DMDFE myself). Maybe someone who played
with the FE can make a quick patch as a proof of concepts, even if the
implementation ignores the annotations completely for now it can be a good
start.
I think the Other thoughts section should be official part of the
proposal if there is any intention to move most of the current attribute
keywords to annotations.
About the version(X) {} else {}, first, version(!X) could be supported as
an ugly hack =P. A more generic approach could be to support annotations
returns. Annotations could return void (in which case the else statement
is a *semantic* error) or bool (in which case the else statement is
supported). The problem with this is that statements should be target for
annotations too, so one can do:
@deprecated
void foo()
{
@version(Foo) writeln(foo);
}
Maybe this one should be delayed for a second stage of annotations =)
--
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
CHINO ATRAPA COTORRAS
-- Crónica TV
Re: DIP guidelines [was: DIP6: Attributes]
Leandro Lucarella, el 1 de agosto a las 20:28 me escribiste: Ary Borenszweig, el 1 de agosto a las 16:29 me escribiste: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6 Please, try to post at least the abstract of the DIP with the link, so people can easily know what is it about =) BTW, you forgot to link the DIP to the DIPs index: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs It's linked now... =) -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) Home, home again. I like to be here when I can. When I come home cold and tired It's good to warm my bones beside the fire.
Re: DIP guidelines [was: DIP6: Attributes]
Leandro Lucarella escribió: Ary Borenszweig, el 1 de agosto a las 16:29 me escribiste: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6 Please, try to post at least the abstract of the DIP with the link, so people can easily know what is it about =) And when writing a DIP, try to make the abstract a little more descriptive. From an abstract you should be able to tell what the DIP is about (in this case explain what an annotation is at least). A oneliner is not good enough, that's just a title, not an abstract. If it's too hard to explain, try to provide a link to somewhere else where the terms are described. The rationale can be a little more descriptive too. What are the advantages of removing keywords for example? Use NG posts links if you have some problems documented there, for example. Try not to explain your opinion in DIPs. They are not NG posts, they should provide facts and be as objective as possible. Even when that's pretty hard, saying I prefer Java's one because ... is excessively subjective. Avoid doing that. You can express the same by saying something like Java syntax has the advantage of ... for example. A section called Other thoughts is not very serious either. If you are not yet convinced about something in the DIP, post it in the announcement post in the NG so it can be discussed and added later to the DIP when the idea is in better shape. Please, don't take this personally, I just want DIPs to be high quality, otherwise they will never be taken seriously. =) I've added this information in a Recommendations subsection to the DIP1, see: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP1#Recommendations I'll address the DIP itself in another post ;) Hola Leandro, I've updated the DIP page with your recommendations. I agree with all of them. Please, can someone (pst, bearophile) check that what I found as decorators in Pyhton are what we are calling annotations here? Thanks!
Re: DIP guidelines [was: DIP6: Attributes]
On Sat, Aug 1, 2009 at 11:27 PM, Ellery Newcomerellery-newco...@utulsa.edu wrote: They aren't. Decorators are deep crazy magic. As I recall, @mydecorator def myfunc(argsnjunk): pass transforms all calls to myfunc to a call to a function you defined somewhere named mydecorator, which takes a function and its arguments as parameters and returns a function which is expected to call the function with its arguments. Then the returned function gets called. Close, but not quite. What instead happens is that this gets transformed into something like: myfunc = mydecorator()(lambda(argsnjunk): pass) That is, mydecorator() returns a callable; that callable takes the function that you're defining as its argument, potentially modifies or transforms it, then returns either the same function or anything else, which is finally stored in myfunc. Calls to myfunc are not transformed at all; all that has happened is that the decorator has intercepted the function definition, and might have replaced the original function with a new one.
