Re: User Defined Attributes
On Tuesday, 6 November 2012 at 18:49:22 UTC, Walter Bright wrote: On 11/6/2012 10:10 AM, Jacob Carlborg wrote: On 2012-11-06 18:00, David Nadlinger wrote: Yes, it is nice to have a working prototype indeed. What is not so nice in my opinion, however, is that this first prototype straight to Git master, without any prior evaluation, at a time where the general goal is to stabilize the language. Yes, very good point. I don't see why this hasn't been done before, it's dead easy. Just use: $ git checkout -b uda # code $ git commit -a -m Add support for user defined attributes $ git push origin uda Walter, why aren't you using branches for these kind of things? Because I still think in a linear fashion :-) hehe, how on earth were you able to come up with D in the first place then? ;-p
Re: User Defined Attributes
On Thursday, 15 November 2012 at 22:04:27 UTC, David Nadlinger
wrote:
On Thursday, 15 November 2012 at 08:45:49 UTC, Tove wrote:
I disagree, you can always fallback to using user defined
types... but it _allows_ for native types also, i.e. more
flexible.
You are missing the point: In your proposal, if you want to use
two libraries together which are expecting you to provide e.g.
'int' annotations, you are screwed. This is a big, BIG problem.
David
no, I implied the solution already... actually there are many
different ways to solve it... some possible today, some require
new minor support features(like sending the annotated symbol as a
template alias parameter to the annotation)... but could give us
compile time errors when ambiguity is detected.
In the common case there are no collisions, so most of the time
we can use the nice user-friendly syntax!
[lib1.x]
struct User
{
[1] int uid;
}
But we _can_ disambiguate when needed...
[lib1.x, lib2.y]
struct User
{
[lib!1, lib2!2] int uid; // ok
[1, lib2!2] int uid; // ok
[lib1!1, 2] int uid; // ok
[1,2] int uid; // not supported
[1] int uid; // not supported
}
lib2 doesn't have to know about lib1.
lib1 doesn't have to know about lib2.
Because they just have to check the annotation in _prioritized_
order.
1. find my unique lib2.y symbol
2. if there is a lib2!uint on a nested symbol, use it...
3. if not check for a native int.
Re: User Defined Attributes
On 11/15/2012 12:22 AM, Jacob Carlborg wrote:
On 2012-11-14 22:13, Walter Bright wrote:
I am having a REALLY hard time making my point here.
struct MyString
{
string s;
}
Just because it is not a builtin type does not change anything.
Sure you _can_ but it would be quite stupid. With user defined types there is at
least some context. With a plain string (or any built in type) it can come from
any where and mean anything.
The difference is, with a user defined type you know the meaning of the
attribute, with a built in type you do not, not in the same way at least.
The whole point of my example was no, you do not necessarily know the meaning of
a user-defined type that is used as an attribute.
Re: User Defined Attributes
On Friday, 16 November 2012 at 10:41:44 UTC, Walter Bright wrote:
The whole point of my example was no, you do not necessarily
know the meaning of a user-defined type that is used as an
attribute.
Agree. Imagine we have 3 generic libs/modules...
Optimized CTFE Polygon Primitive Lib, Math, Gfx
... and then the end user, creates a program.
Both Math and Gfx, want to use the optimized Polygon in their
modules...
[Polygon(...)]
struct SpaceShip
{
}
This is just as ambiguous as if you had used a built-in int:s...
and it can be solved in the exact same way which I outlined in
the other thread.
Re: User Defined Attributes
Le 14/11/2012 22:13, Walter Bright a écrit :
On 11/14/2012 2:53 AM, Jacob Carlborg wrote:
If std.mytypes.mystring is a variable of the type string then the
fully
qualified name is lost if it's used as an attribute. Something like this:
I am having a REALLY hard time making my point here.
struct MyString
{
string s;
}
Now use MyString as an attribute. No, the name is not lost. Yes, two
different modules can use MyString as an attribute, and impute
completely different meanings into it.
Just because it is not a builtin type does not change anything.
I seriously feel like I'm in Alice in wonderland here.
A type is a meaning associated to data. For instance, char[] is an array
of char. Note that you can store pointers, integer, or basically
anything in that memory. But you don't, because this type give you
information about what in this memory, and storing anything else would
be confusing as hell.
The same way, I can throw a FileExeption every time a problem occurs in
any of my programs. That would be insane, but i CAN do that.
Well, the same way, I can subvert attribute in any convoluted way I want
to. But that make no sens at all (and I don't expect any codebase using
such techniques to become really big).
The whole point of attaching data to a symbol via attribute is to
provide a meaning attached to that symbol. The meaning is given by the
type, like it does everywhere else.
Your MyString example or an int is a perfect example of a type that have
no meaning. Your argument is just like we shouldn't put any protection
near a precipice since people can throw themselves over it anyway. Yeah,
but at least, they'll do it on purpose and assume the consequences, and
that is a huge win.
Re: User Defined Attributes
On 11/14/2012 2:18 AM, Leandro Lucarella wrote: Can you provide one concrete case where it makes sense NOT to restrict UDAs to types One where its use is entirely inside the scope of a module, i.e. local use of it. There seems to be an assumption that UDAs are global, but I don't see a reason why that should always be true. and it's different from restricting exception to classes derived from Exception? Exceptions leak out of their scopes as an explicit part of their nature. That's the whole point of them, and I think that's the fundamental difference.
Re: User Defined Attributes
On Friday, 16 November 2012 at 13:12:34 UTC, Tove wrote:
On Friday, 16 November 2012 at 10:41:44 UTC, Walter Bright
wrote:
The whole point of my example was no, you do not necessarily
know the meaning of a user-defined type that is used as an
attribute.
Agree. Imagine we have 3 generic libs/modules...
Optimized CTFE Polygon Primitive Lib, Math, Gfx
... and then the end user, creates a program.
Both Math and Gfx, want to use the optimized Polygon in their
modules...
[Polygon(...)]
struct SpaceShip
{
}
This is just as ambiguous as if you had used a built-in
int:s... and it can be solved in the exact same way which I
outlined in the other thread.
I don't think this is a valid argument. I challenge you to find a
single real-world use case where an *annotation* would be so
complex that this would make any sense at all, yet it would be
impossible (or even just less clear) to just use a wrapper type
like @CollisionShape(Polygon(…)) or @RenderBounds(Polygon(…)).
David
Re: User Defined Attributes
On 2012-11-16 11:41, Walter Bright wrote: Sure you _can_ but it would be quite stupid. With user defined types there is at least some context. With a plain string (or any built in type) it can come from any where and mean anything. The difference is, with a user defined type you know the meaning of the attribute, with a built in type you do not, not in the same way at least. The whole point of my example was no, you do not necessarily know the meaning of a user-defined type that is used as an attribute. i don't know what to say anymore. I can only repeat what I've already said. This conversion has clearly gone into circles. -- /Jacob Carlborg
Re: User Defined Attributes
On 2012-11-14 22:13, Walter Bright wrote:
I am having a REALLY hard time making my point here.
struct MyString
{
string s;
}
Just because it is not a builtin type does not change anything.
Sure you _can_ but it would be quite stupid. With user defined types
there is at least some context. With a plain string (or any built in
type) it can come from any where and mean anything.
The difference is, with a user defined type you know the meaning of the
attribute, with a built in type you do not, not in the same way at least.
--
/Jacob Carlborg
Re: User Defined Attributes
On 2012-11-14 23:39, Andrei Alexandrescu wrote: I think a simple way to put this is that attribute name lookup works the same as ordinary symbol lookup. Assuming we did a good job at the latter, the former doesn't introduce any specific issues. Exactly. -- /Jacob Carlborg
Re: User Defined Attributes
On Wednesday, 14 November 2012 at 23:57:38 UTC, David Nadlinger wrote: Also, your solution is more complex than simply using types, yet less flexible: What if you want to use uint attributes from two libraries on the same type? David I disagree, you can always fallback to using user defined types... but it _allows_ for native types also, i.e. more flexible.
Re: User Defined Attributes
Timon Gehr, el 14 de November a las 17:25 me escribiste:
On 11/14/2012 03:31 PM, Leandro Lucarella wrote:
Tove, el 14 de November a las 13:55 me escribiste:
struct UserProfile {
@Id(1) i32 uid;
@Id(2) string name;
@Id(3) string blurb;
}
Where Id is thrift.attributes.Id or something similar.
well, similar... but beginning with a symbol...
[thrift.attributes.Definition]
struct UserProfile
{
[1] i32 uid;
[2] string name;
[3] string blurb;
}
OK, that's just a good example of convenience of allowing native types, but I
think it is still potentially harmful. What if you pass that struct to
another
library that have another meaning attached to int annotations? How could you
tell that library that this particular int annotations is not for it?
...
By not telling it that they are for it. Note that the
[thrift.attributes.Definition] annotation is significant.
Yes, but that only tells thrift how to interpret those ints, it doesn't tell
any other module they *shouldn't* interpret them. Or are you suggesting every
module that want to attach meaning to an int attribute should check if the
parent module doesn't have any other attribute attached to it?
I mean, it convenient to be able to throw numbers or strings too:
void f() { throw 1; }
void g() { throw error; }
int main()
{
try {
g();
} catch (char[] e) {
writefln(e);
}
try {
f();
} catch (int i) {
return i;
}
return 0;
}
What he does is more like (but not exactly like):
class ThriftException{
int x;
this(int x){ this.x = x; }
}
I don't know what does this mean.
--
Re: User Defined Attributes
On Thursday, 15 November 2012 at 08:45:49 UTC, Tove wrote: I disagree, you can always fallback to using user defined types... but it _allows_ for native types also, i.e. more flexible. You are missing the point: In your proposal, if you want to use two libraries together which are expecting you to provide e.g. 'int' annotations, you are screwed. This is a big, BIG problem. David
Re: User Defined Attributes
On 2012-11-14 08:46, Walter Bright wrote:
We agree that strings can be used globally as attributes with different
meanings, right?
Yes, but I would consider that a bad idea.
So why can't test.foo.bar also be used globally as an attribute with
different meanings? It's just a type name, it has no magic property that
says it cannot be used for different purposes.
I guess it could. But there is no way of preventing the user from doing
stupid things. I can create a map container out of two arrays, but
that's not how arrays are intended to be used.
Ok, let's call it:
std.mytypes.mystring
? Now have those string contents mean different things to different
users of std.mytypes.mystring.
If std.mytypes.mystring is a variable of the type string then the
fully qualified name is lost if it's used as an attribute. Something
like this:
[std.mytypes.mystring] int a;
pragma(msg, __traits(getAttributes, a).stringof);
Would result in:
(foo)
pragma(msg, typeof(__traits(getAttributes, a)).stringof);
Would result in:
(string)
The name std.mytypes.mystring is gone. You have no idea where the
string came from, who could have put it there. You would need to put the
fully qualified name in the content of the string:
module std.mytypes;
string mystring = std.mytypes.mystring;
The whole problem with this is that there is no actual thing called
attribute, there are just symbols with attached values.
In most cases I think it's the symbol/type name that is interesting. I
imagine many attributes just look like this:
@attribute struct Serializable {}
I would prefer that only user defined types explicitly marked with
@attribute (or similar) could be used as attributes. And preferably,
that they cannot be used for anything else.
If only user defined types (and preferably marked with @attribute) are
allowed then you can know exactly where a given attribute comes from and
you can look up the documentation. Sure you cannot prevent anyone from
using the attribute with a different meaning then it was intended for.
But that's true for many other things in programming as well.
--
/Jacob Carlborg
Re: User Defined Attributes
Walter Bright, el 13 de November a las 16:49 me escribiste: On 11/13/2012 2:55 PM, bearophile wrote: Walter Bright: consider the type int. Different modules impute different meanings into it all the time, and it doesn't cause terrible compatibility problems between modules. The usage of naked basic types as int and double cause troubles. I know that you can use custom types instead, and have better type checking, etc., and can be a pretty good idea for a lot of use cases. But D does not require that. It's up to the programmer. What really amazes me is how you always defend the will not be included until real uses cases can be shown and in this case you are doing the exact opposite. Can you provide any real uses cases instead of talking about a completely theoretical and hypothetical cases? Can you provide one concrete case where it makes sense NOT to restrict UDAs to types and it's different from restricting exception to classes derived from Exception? Thank you. --
Re: User Defined Attributes
On Wednesday, 14 November 2012 at 11:08:04 UTC, Leandro Lucarella
wrote:
Can you provide one concrete case where it makes sense NOT to
restrict UDAs to
types and it's different from restricting exception to classes
derived from
Exception?
Thank you.
There was the example with Thrift...
struct UserProfile {
1: i32 uid,
2: string name,
3: string blurb
}
service UserStorage {
void store(1: UserProfile user),
UserProfile retrieve(1: i32 uid)
}
You could use a user defined type for the struct... but for the
members it would make sense to use the native type directly...
and if you traverse the annotation in sequence rather than as
standalone entities.. it's perfectly safe to use 1,2,3 as
annotation...
i.e. first scan for the Thrift symbol, then scan for native typed
int:s...
Re: User Defined Attributes
On 2012-11-14 12:18, Tove wrote:
On Wednesday, 14 November 2012 at 11:08:04 UTC, Leandro Lucarella wrote:
Can you provide one concrete case where it makes sense NOT to restrict
UDAs to
types and it's different from restricting exception to classes derived
from
Exception?
Thank you.
There was the example with Thrift...
struct UserProfile {
1: i32 uid,
2: string name,
3: string blurb
}
service UserStorage {
void store(1: UserProfile user),
UserProfile retrieve(1: i32 uid)
}
You could use a user defined type for the struct... but for the members
it would make sense to use the native type directly... and if you
traverse the annotation in sequence rather than as standalone entities..
it's perfectly safe to use 1,2,3 as annotation...
i.e. first scan for the Thrift symbol, then scan for native typed int:s...
I assume you mean something like:
struct UserProfile {
[1] i32 uid;
[2] string name;
[3] string blurb;
}
In that case I would much rather prefer this:
struct UserProfile {
@Id(1) i32 uid;
@Id(2) string name;
@Id(3) string blurb;
}
Where Id is thrift.attributes.Id or something similar.
--
/Jacob Carlborg
Re: User Defined Attributes
On Wednesday, 14 November 2012 at 12:33:58 UTC, Jacob Carlborg
wrote:
I assume you mean something like:
struct UserProfile {
[1] i32 uid;
[2] string name;
[3] string blurb;
}
In that case I would much rather prefer this:
struct UserProfile {
@Id(1) i32 uid;
@Id(2) string name;
@Id(3) string blurb;
}
Where Id is thrift.attributes.Id or something similar.
well, similar... but beginning with a symbol...
[thrift.attributes.Definition]
struct UserProfile
{
[1] i32 uid;
[2] string name;
[3] string blurb;
}
Re: User Defined Attributes
On Wednesday, 14 November 2012 at 11:18:28 UTC, Tove wrote:
There was the example with Thrift...
struct UserProfile {
1: i32 uid,
2: string name,
3: string blurb
}
service UserStorage {
void store(1: UserProfile user),
UserProfile retrieve(1: i32 uid)
}
You could use a user defined type for the struct... but for the
members it would make sense to use the native type directly...
and if you traverse the annotation in sequence rather than as
standalone entities.. it's perfectly safe to use 1,2,3 as
annotation...
But what if you want to use that struct with another library as
well, for which you might also want to tack some ids on the
fields? I'm the author of the current D implementation in Thrift,
and if/when user defined attributes become stable and I'll amend
it to take advantage of UDAs, I'll definitely not go for raw
literals…
David
Re: User Defined Attributes
On Wednesday, 14 November 2012 at 13:03:18 UTC, David Nadlinger
wrote:
On Wednesday, 14 November 2012 at 11:18:28 UTC, Tove wrote:
There was the example with Thrift...
struct UserProfile {
1: i32 uid,
2: string name,
3: string blurb
}
service UserStorage {
void store(1: UserProfile user),
UserProfile retrieve(1: i32 uid)
}
You could use a user defined type for the struct... but for
the members it would make sense to use the native type
directly... and if you traverse the annotation in sequence
rather than as standalone entities.. it's perfectly safe to
use 1,2,3 as annotation...
But what if you want to use that struct with another library as
well, for which you might also want to tack some ids on the
fields? I'm the author of the current D implementation in
Thrift, and if/when user defined attributes become stable and
I'll amend it to take advantage of UDAs, I'll definitely not go
for raw literals…
David
// in this nested scope, all uints are interpreted as belonging
to the thrift module.
[std.attributes(uint, thrift)]
struct UserProfile
...
// error detected at compile-time
[std.attributes(uint, thrift), std.attributes(uint, thrift2)]
struct UserProfile
...
Re: User Defined Attributes
Tove, el 14 de November a las 13:55 me escribiste:
struct UserProfile {
@Id(1) i32 uid;
@Id(2) string name;
@Id(3) string blurb;
}
Where Id is thrift.attributes.Id or something similar.
well, similar... but beginning with a symbol...
[thrift.attributes.Definition]
struct UserProfile
{
[1] i32 uid;
[2] string name;
[3] string blurb;
}
OK, that's just a good example of convenience of allowing native types, but I
think it is still potentially harmful. What if you pass that struct to another
library that have another meaning attached to int annotations? How could you
tell that library that this particular int annotations is not for it?
I mean, it convenient to be able to throw numbers or strings too:
void f() { throw 1; }
void g() { throw error; }
int main()
{
try {
g();
} catch (char[] e) {
writefln(e);
}
try {
f();
} catch (int i) {
return i;
}
return 0;
}
--
Re: User Defined Attributes
On 11/14/2012 03:31 PM, Leandro Lucarella wrote:
Tove, el 14 de November a las 13:55 me escribiste:
struct UserProfile {
@Id(1) i32 uid;
@Id(2) string name;
@Id(3) string blurb;
}
Where Id is thrift.attributes.Id or something similar.
well, similar... but beginning with a symbol...
[thrift.attributes.Definition]
struct UserProfile
{
[1] i32 uid;
[2] string name;
[3] string blurb;
}
OK, that's just a good example of convenience of allowing native types, but I
think it is still potentially harmful. What if you pass that struct to another
library that have another meaning attached to int annotations? How could you
tell that library that this particular int annotations is not for it?
...
By not telling it that they are for it. Note that the
[thrift.attributes.Definition] annotation is significant.
I mean, it convenient to be able to throw numbers or strings too:
void f() { throw 1; }
void g() { throw error; }
int main()
{
try {
g();
} catch (char[] e) {
writefln(e);
}
try {
f();
} catch (int i) {
return i;
}
return 0;
}
What he does is more like (but not exactly like):
class ThriftException{
int x;
this(int x){ this.x = x; }
}
Re: User Defined Attributes
On 11/14/2012 2:53 AM, Jacob Carlborg wrote:
If std.mytypes.mystring is a variable of the type string then the fully
qualified name is lost if it's used as an attribute. Something like this:
I am having a REALLY hard time making my point here.
struct MyString
{
string s;
}
Now use MyString as an attribute. No, the name is not lost. Yes, two different
modules can use MyString as an attribute, and impute completely different
meanings into it.
Just because it is not a builtin type does not change anything.
Re: User Defined Attributes
On 11/14/12 1:13 PM, Walter Bright wrote:
On 11/14/2012 2:53 AM, Jacob Carlborg wrote:
If std.mytypes.mystring is a variable of the type string then the
fully
qualified name is lost if it's used as an attribute. Something like this:
I am having a REALLY hard time making my point here.
struct MyString
{
string s;
}
Now use MyString as an attribute. No, the name is not lost. Yes, two
different modules can use MyString as an attribute, and impute
completely different meanings into it.
Just because it is not a builtin type does not change anything.
I think a simple way to put this is that attribute name lookup works the
same as ordinary symbol lookup. Assuming we did a good job at the
latter, the former doesn't introduce any specific issues.
Andrei
Re: User Defined Attributes
On Wednesday, 14 November 2012 at 13:28:05 UTC, Tove wrote: // in this nested scope, all uints are interpreted as belonging to the thrift module. [std.attributes(uint, thrift)] struct UserProfile ... // error detected at compile-time [std.attributes(uint, thrift), std.attributes(uint, thrift2)] struct UserProfile ... »interpreted as belonging to the thrift module« – what do you even mean by that? As of now, UDAs are just a way to tuck arbitrary symbols onto declarations. There is no concept of »belonging« to a module, and I don't think there should be. Also, your solution is more complex than simply using types, yet less flexible: What if you want to use uint attributes from two libraries on the same type? David
Re: User Defined Attributes
On Wednesday, 14 November 2012 at 13:28:05 UTC, Tove wrote: // in this nested scope, all uints are interpreted as belonging to the thrift module. [std.attributes(uint, thrift)] struct UserProfile ... // error detected at compile-time [std.attributes(uint, thrift), std.attributes(uint, thrift2)] struct UserProfile ... »interpreted as belonging to the thrift module« – what do you even mean by that? As of now, UDAs are just a way to tuck arbitrary symbols onto declarations. There is no concept of »belonging« to a module, and I don't think there should be. Also, your solution is more complex than simply using types, yet less flexible: What if you want to use uint attributes from two libraries on the same type? David
Re: User Defined Attributes
On Wednesday, 14 November 2012 at 13:28:05 UTC, Tove wrote: // in this nested scope, all uints are interpreted as belonging to the thrift module. [std.attributes(uint, thrift)] struct UserProfile ... // error detected at compile-time [std.attributes(uint, thrift), std.attributes(uint, thrift2)] struct UserProfile ... »interpreted as belonging to the thrift module« – what do you even mean by that? As of now, UDAs are just a way to tuck arbitrary symbols onto declarations. There is no concept of »belonging« to a module, and I don't think there should be. Also, your solution is more complex than simply using types, yet less flexible: What if you want to use uint attributes from two libraries on the same type? David
Re: User Defined Attributes
On 11/10/2012 11:15 AM, Jacob Carlborg wrote: On 2012-11-10 20:04, Walter Bright wrote: Think of it this way. If I have myString.String, and use the strings in it as an attribute in one module, and in another use module use myString.String as an attribute with a totally different meaning, that will not work if plugins are used. I'm not entirely sure what you're meaning here but if you have two symbols with the same name in two different modules their fully qualified names won't be the same. If you're referring to using a string literal as an attribute then that would be a bad thing, like we have tried to explain. It's better to use a type which will have a unique name. If I have misunderstood what you're meaning could you provide a code example? That is what I mean, and it also applies to a library type which different modules may press into service as attributes.
Re: User Defined Attributes
On 11/10/2012 12:21 PM, deadalnix wrote: Thinking of it this way don't make any sense. The whole point of an attribute is to tell a library about how to understand your code. If many library uses the same attribute, then it defeat the whole point of having attribute. This is why the discussion about disallowing any type as UDA exists in the first place. I understand that. I just am not convinced of the scope of this issue, and I am not convinced that a runtime attribute system is that applicable for this case, nor am I convinced that exception handling is that applicable (all for reasons already explained). For another analogy, consider the type int. Different modules impute different meanings into it all the time, and it doesn't cause terrible compatibility problems between modules.
Re: User Defined Attributes
On 11/13/2012 2:55 PM, bearophile wrote: Walter Bright: consider the type int. Different modules impute different meanings into it all the time, and it doesn't cause terrible compatibility problems between modules. The usage of naked basic types as int and double cause troubles. I know that you can use custom types instead, and have better type checking, etc., and can be a pretty good idea for a lot of use cases. But D does not require that. It's up to the programmer.
Re: User Defined Attributes
Walter Bright: (I know this sub-discussion is a bit OT, but not too much, and I think it's not wasted time.) But D does not require that. It's up to the programmer. Oh, but the use of newtype is not required in Haskell; programmers are free to use it, or to use normal basic types as Int, Integer, Double, etc. Probably newtype is not that useful in little programs. And even in larger programs it's better to not use it too much. And the use of that using in a newtype is not standard Haskell, it's a GHC compiler extension to the language, that you have to ask with a compilation switch or an annotation inside the code. That using attached to a newtype allows you to both use a newtype like its base type (like the underlying Int), or to choose where the newtype must not do what its base type is able to do (this technically means what typeclasses it conforms to or not). I think D Typedef should allow something similar, despite D has no typeclasses. As an example, currently D Typedef is kind of useless if you want to use it to define a new array type. Bye, bearophile
Re: User Defined Attributes
On 11/13/2012 5:22 PM, bearophile wrote: As an example, currently D Typedef is kind of useless if you want to use it to define a new array type. D's typedef is deprecated, as nobody could figure out what it was good for or properly define its semantics.
Re: User Defined Attributes
Le 13/11/2012 23:27, Walter Bright a écrit : On 11/10/2012 12:21 PM, deadalnix wrote: Thinking of it this way don't make any sense. The whole point of an attribute is to tell a library about how to understand your code. If many library uses the same attribute, then it defeat the whole point of having attribute. This is why the discussion about disallowing any type as UDA exists in the first place. I understand that. I just am not convinced of the scope of this issue, and I am not convinced that a runtime attribute system is that applicable for this case, nor am I convinced that exception handling is that applicable (all for reasons already explained). I presented you compile time uses cases for such a mecanism already. See project lombok for instance. For another analogy, consider the type int. Different modules impute different meanings into it all the time, and it doesn't cause terrible compatibility problems between modules. int isn't meant to be discovered. The whole point of attribute is to be discovered.
Re: User Defined Attributes
Walter Bright: D's typedef is deprecated, as nobody could figure out what it was good for or properly define its semantics. Look better, in both my last posts Typedef was std.typecons.Typedef. Bye, bearophile
Re: User Defined Attributes
On 2012-11-13 23:24, Walter Bright wrote: That is what I mean, and it also applies to a library type which different modules may press into service as attributes. I think there must be some kind of misunderstanding here. I still don't see the problem if fully qualified symbols are used. I mean, it will be unique. -- /Jacob Carlborg
Re: User Defined Attributes
On 11/13/2012 11:16 PM, Jacob Carlborg wrote: On 2012-11-13 23:24, Walter Bright wrote: That is what I mean, and it also applies to a library type which different modules may press into service as attributes. I think there must be some kind of misunderstanding here. I still don't see the problem if fully qualified symbols are used. I mean, it will be unique. We agree that strings can be used globally as attributes with different meanings, right? So why can't test.foo.bar also be used globally as an attribute with different meanings? It's just a type name, it has no magic property that says it cannot be used for different purposes. Ok, let's call it: std.mytypes.mystring ? Now have those string contents mean different things to different users of std.mytypes.mystring.
Re: User Defined Attributes
On 2012-11-10 05:02, Walter Bright wrote: Meaning a given attribute can have only one, global, meaning. Isn't that true for any symbol. Can I have two std.stdio.writeln symbols in the same application? -- /Jacob Carlborg
Re: User Defined Attributes
Le 10/11/2012 05:02, Walter Bright a écrit : On 11/9/2012 6:28 PM, deadalnix wrote: Le 08/11/2012 11:56, Walter Bright a écrit : On 11/7/2012 11:27 PM, Jacob Carlborg wrote: On 2012-11-08 02:49, Walter Bright wrote: Yes, that makes the attribute global. I don't actually know how this works in Java but if you are forced to use the fully qualified name for the attribute it won't make the attribute global. A plugin would apply globally, wouldn't it? No it would apply on symbols qualified with a given attribute (provided by the plugin). Meaning a given attribute can have only one, global, meaning. Yes, it have to. What is the point of attaching an attribute is you cannot know what meaning it has ? If an attribute can have ambiguous meaning, then it defeat the whole point of having attribute.
Re: User Defined Attributes
On 11/10/2012 1:59 AM, Jacob Carlborg wrote: On 2012-11-10 05:02, Walter Bright wrote: Meaning a given attribute can have only one, global, meaning. Isn't that true for any symbol. Can I have two std.stdio.writeln symbols in the same application? Think of it this way. If I have myString.String, and use the strings in it as an attribute in one module, and in another use module use myString.String as an attribute with a totally different meaning, that will not work if plugins are used.
Re: User Defined Attributes
On 2012-11-10 20:04, Walter Bright wrote: Think of it this way. If I have myString.String, and use the strings in it as an attribute in one module, and in another use module use myString.String as an attribute with a totally different meaning, that will not work if plugins are used. I'm not entirely sure what you're meaning here but if you have two symbols with the same name in two different modules their fully qualified names won't be the same. If you're referring to using a string literal as an attribute then that would be a bad thing, like we have tried to explain. It's better to use a type which will have a unique name. If I have misunderstood what you're meaning could you provide a code example? -- /Jacob Carlborg
Re: User Defined Attributes
Le 10/11/2012 20:04, Walter Bright a écrit : On 11/10/2012 1:59 AM, Jacob Carlborg wrote: On 2012-11-10 05:02, Walter Bright wrote: Meaning a given attribute can have only one, global, meaning. Isn't that true for any symbol. Can I have two std.stdio.writeln symbols in the same application? Think of it this way. If I have myString.String, and use the strings in it as an attribute in one module, and in another use module use myString.String as an attribute with a totally different meaning, that will not work if plugins are used. Thinking of it this way don't make any sense. The whole point of an attribute is to tell a library about how to understand your code. If many library uses the same attribute, then it defeat the whole point of having attribute. This is why the discussion about disallowing any type as UDA exists in the first place.
Re: User Defined Attributes
Le 08/11/2012 11:56, Walter Bright a écrit : On 11/7/2012 11:27 PM, Jacob Carlborg wrote: On 2012-11-08 02:49, Walter Bright wrote: Yes, that makes the attribute global. I don't actually know how this works in Java but if you are forced to use the fully qualified name for the attribute it won't make the attribute global. A plugin would apply globally, wouldn't it? No it would apply on symbols qualified with a given attribute (provided by the plugin).
Re: User Defined Attributes
On 11/9/2012 6:28 PM, deadalnix wrote: Le 08/11/2012 11:56, Walter Bright a écrit : On 11/7/2012 11:27 PM, Jacob Carlborg wrote: On 2012-11-08 02:49, Walter Bright wrote: Yes, that makes the attribute global. I don't actually know how this works in Java but if you are forced to use the fully qualified name for the attribute it won't make the attribute global. A plugin would apply globally, wouldn't it? No it would apply on symbols qualified with a given attribute (provided by the plugin). Meaning a given attribute can have only one, global, meaning.
Re: User Defined Attributes
On 11/8/12 12:20 AM, Walter Bright wrote: One last thing. Sure, string attributes can (and surely would be) used for different purposes in different libraries. The presumption is that this would cause a conflict. But would it? There are two aspects to a UDA - the attribute itself, and the symbol it is attached to. In order to get the UDA for a symbol, one has to look up the symbol. There isn't a global repository of symbols in D. You'd have to say I want to look in module X for symbols. Why would you look in module X for an attribute that you have no reason to believe applies to symbols from X? How would an attribute for module X's symbols leak out of X on their own? Actually there's a stark difference between string attributes and symbol attributes (assuming I understand the point): attribute lookup and potential ambiguity are solved using regular symbol lookup and potential ambiguity - by using name resolution. In contrast, string attributes have no other resolution mechanism than string comparison. So now say two modules moda and modb define an attribute untainted with distinct semantics. If untainted is a string, there's no way out of this - the modules simply cannot work together. In contrast, if untainted is a regular symbol, it will cause ambiguity errors that are solvable by using qualified lookup a la moda.untainted and modb.untainted. Andrei
Re: User Defined Attributes
On Thursday, 8 November 2012 at 09:08:23 UTC, Max Samukha wrote: alias getAttribute!(b, foo) t; Ignore that line.
Re: User Defined Attributes
On 11/7/2012 11:27 PM, Jacob Carlborg wrote: On 2012-11-08 02:49, Walter Bright wrote: Yes, that makes the attribute global. I don't actually know how this works in Java but if you are forced to use the fully qualified name for the attribute it won't make the attribute global. A plugin would apply globally, wouldn't it?
Re: User Defined Attributes
On 2012-11-08 11:56, Walter Bright wrote: A plugin would apply globally, wouldn't it? Yes, but that wouldn't make the attribute global. I just had a quick look on the Annotation Processing Tool (APT) available in Java. This tool will run an annotation processor over some specified Java files. It will then generate a new set of files with the result of the annotation process. In the annotation processor you have to specify what annotations you want to process. You can either specify you want to process all annotations, *, or a single annotation, foo.bar.Baz. http://docs.oracle.com/javase/1.5.0/docs/guide/apt/GettingStarted.html -- /Jacob Carlborg
Re: User Defined Attributes
On 2012-11-08 10:08, Max Samukha wrote: Could you explain why it is impossible without complicating the current state of things? I gave it a quick try and it seems to work reasonably well (a proper implementation will be more involved due to compiler bugs and language issues irrelevant to this discussion): I just see no point in allowing random structs and classes acting like attributes. Suddenly someone starts to use your struct as an attribute without you having any intention of it acting like an attribute and you don't know about it. -- /Jacob Carlborg
Re: User Defined Attributes
On Thursday, 8 November 2012 at 12:42:38 UTC, Jacob Carlborg wrote: On 2012-11-08 10:08, Max Samukha wrote: Could you explain why it is impossible without complicating the current state of things? I gave it a quick try and it seems to work reasonably well (a proper implementation will be more involved due to compiler bugs and language issues irrelevant to this discussion): I just see no point in allowing random structs and classes acting like attributes. Suddenly someone starts to use your struct as an attribute without you having any intention of it acting like an attribute and you don't know about it. The problem is where to draw the line. There is nothing to stop an idiot programmer from applying your attributes to a wrong target, so we'd better take care of that by introducing those target-restricting attributes specially treated by the compiler. Instead of throwing attributes on attributes, I'd rather have decorators based on templates as someone proposed. Those would allow the programmer to implement arbitrary restrictions on their usage.
Re: User Defined Attributes
On 11/8/2012 4:37 AM, Jacob Carlborg wrote: On 2012-11-08 11:56, Walter Bright wrote: A plugin would apply globally, wouldn't it? Yes, but that wouldn't make the attribute global. I just had a quick look on the Annotation Processing Tool (APT) available in Java. This tool will run an annotation processor over some specified Java files. It will then generate a new set of files with the result of the annotation process. In the annotation processor you have to specify what annotations you want to process. You can either specify you want to process all annotations, *, or a single annotation, foo.bar.Baz. http://docs.oracle.com/javase/1.5.0/docs/guide/apt/GettingStarted.html I believe that does have the essential effect of making the attribute global.
Re: User Defined Attributes
On 2012-11-08 20:39, Walter Bright wrote: I believe that does have the essential effect of making the attribute global. I don't understand how. -- /Jacob Carlborg
Re: User Defined Attributes
On Wednesday, 7 November 2012 at 08:41:48 UTC, Walter Bright wrote: New version up now with a couple reported problems with UDA fixed. I may have found a little glitch...? mixin([1] int a;); [[2] int b;] int c; mixin(__traits(getAttributes, c)[0]); pragma(msg, __traits(getAttributes, a)); = tuple() pragma(msg, __traits(getAttributes, b)); = tuple() The use-case for this is parsing a foreign language which will be compiled to mixed in d-code.
Re: User Defined Attributes
On 11/8/2012 12:00 PM, Jacob Carlborg wrote: On 2012-11-08 20:39, Walter Bright wrote: I believe that does have the essential effect of making the attribute global. I don't understand how. Because plugins are a global thing. If you have a plugin that deals with attribute 'X', then you cannot have two plugins that interpret 'X' differently, i.e. 'X' becomes, for all practical purposes, global.
Re: User Defined Attributes
On 2012-11-08 23:31, Walter Bright wrote: Because plugins are a global thing. If you have a plugin that deals with attribute 'X', then you cannot have two plugins that interpret 'X' differently, i.e. 'X' becomes, for all practical purposes, global. Well, 'X' is supposed to be the fully qualified name. Can I have my own symbol named std.algorithm.filter and use it together with the std.algorithm.filter function in Phobos? -- /Jacob Carlborg
Re: User Defined Attributes
On 2012-11-08 19:03, Max Samukha wrote: The problem is where to draw the line. There is nothing to stop an idiot programmer from applying your attributes to a wrong target, so we'd better take care of that by introducing those target-restricting attributes specially treated by the compiler. Sure, but we don't want to have a comment for every struct indented as an attribute saying this is an attribute. We do have const, pure, nothrow and so on for a reason. We want the compiler to be able to force/validate our intent and not have to write the intention in the documentation. -- /Jacob Carlborg
Re: User Defined Attributes
On 2012-39-06 20:11, Jacob Carlborg d...@me.com wrote:
On 2012-11-06 19:24, David Nadlinger wrote:
You are right, UDAs must definitely leverage D's module system for
encapsulation/disambiguation. Use of string literals (which are
intrinsically »global«) as annotations needs to be explicitly
discouraged.
Then why allow it in the first place?
Because string literals are just a special case of literals?
i.e. if this works:
struct MyString {
string s;
alias s this;
}
@MyString(Foo) int n;
then why should this not work:
@Foo int n;
I agree it's useless, but it seems a very arbitrary restriction, too.
--
Simen
Re: User Defined Attributes
On 11/07/2012 08:08 AM, Daniel Murphy wrote:
Walter Bright newshou...@digitalmars.com wrote in message
news:k7cko9$hes$1...@digitalmars.com...
On 11/6/2012 6:10 PM, Daniel Murphy wrote:
My thoughts exactly. It reminds me of the horror of C++ exceptions. I
think it would be reasonable to require every annotation is a struct or
class.
Good analogy. But I'm not sure at this point if that is the right thing to
do.
I don't know if it will turn out to be useful either. But if it's left in
there, right or wrong, people will use it and it will be impossible to
remove later.
If two libraries both use string literal annotations for metadata (and they
will) you can no longer use both on the same declaration at once. This
leads back to C/C++'s global namespace.
As an example:
[3] class Blah {}
What on earth is 3? Why would you want to attach 3 to a class declaration?
How many different ways are there for libraries to interpret this?
Most importantly, if users still want to experiment with anonymous
annotations, they still can:
[tuple(3)] class Blah {}
Then what does this particular restriction buy?
Adding speculative features with no use case in mind is a recipe for
disaster.
Much like how you can use extern(C) to force global visibility, you can
still get the less hygienic behaviour, if you explicitly ask for it.
We lose nothing. If it turns out this was the wrong call, built-in types
can be restored without breaking a single line of code.
That is never a given in D.
static assert(!is(typeof({struct S{ [2] int x; }})));
Re: User Defined Attributes
On Wednesday, November 07, 2012 13:01:52 Jacob Carlborg wrote:
On 2012-11-07 12:05, Leandro Lucarella wrote:
OK, that's another thing. And maybe a reason for listening to people
having
more experience with UDAs than you.
For me the analogy with Exceptions is pretty good. The issues an
conveniences of throwing anything or annotating a symbol with anything
instead of just type are pretty much the same. I only see functions
making sense to be accepted as annotations too (that's what Python do
with annotations, @annotation symbol is the same as symbol =
annotation(symbol), but is quite a different language).
I start to more and more think it would be better to explicitly require
the developer to declare an attribute, like:
attribute foo
{
string name;
}
@foo(asd) int a;
Isn't that how it works in Java? It's been a while since I've done much with
Java, but IIRC that's essentially how it works in Java.
- Jonathan M Davis
Re: User Defined Attributes
Don Clugston, el 7 de November a las 09:23 me escribiste: If you have no idea what my point is, I'm probably wasting my time working on D. If you mean, we should be working on getting the existing stuff working before we think about adding more stuff, I agree 100%. I would say we're about three years away from it being sensible to work on annotations. It's reasonable to draft a preliminary proposal (A roadmap, what a novel concept!). But I think it would be a big mistake to do much work on it. 100% agree. It might make a little sense if it were in an experimental branch for people to try out and find bugs. But it makes no sense to keep adding features to the stable branch, when a release should be made soon, out of the blue like this just because Walter woke up one day with an idea. Seriously Walter, please do some planing and consult with the other developers before committing stuff to the master branch, if you keep treating the language as your own toy. It would be very difficult for people to perceive it as a real open source and community driven project if you keep doing that. -- Luca
Re: User Defined Attributes
On 2012-11-07 13:08, Jonathan M Davis wrote: Isn't that how it works in Java? It's been a while since I've done much with Java, but IIRC that's essentially how it works in Java. Yes, exactly, just with a slightly different syntax. http://docs.oracle.com/javase/1.5.0/docs/guide/language/annotations.html -- /Jacob Carlborg
Re: User Defined Attributes
Le 07/11/2012 13:01, Jacob Carlborg a écrit :
On 2012-11-07 12:05, Leandro Lucarella wrote:
OK, that's another thing. And maybe a reason for listening to people
having
more experience with UDAs than you.
For me the analogy with Exceptions is pretty good. The issues an
conveniences
of throwing anything or annotating a symbol with anything instead of just
type are pretty much the same. I only see functions making sense to be
accepted
as annotations too (that's what Python do with annotations,
@annotation symbol
is the same as symbol = annotation(symbol), but is quite a different
language).
I start to more and more think it would be better to explicitly require
the developer to declare an attribute, like:
attribute foo
{
string name;
}
@foo(asd) int a;
Yes that was pretty close to what my proposal looked like in the big
annotation thread, except I used @ttribute .
Re: User Defined Attributes
Le 07/11/2012 05:19, Walter Bright a écrit : On 11/6/2012 7:52 PM, bearophile wrote: Walter Bright: But I'm not sure at this point if that is the right thing to do. Why? D was fortunate in having 10 years of experience with C++'s exception system to learn from. We don't have that with UDAs. [If you decide to restrict UDAs, then later it will be easy to extend them, it will not break code. While doing the opposite break code. It's you the one that has taught me to design things this way :-) ] It's a good point, but I have no experience with UDAs. There may be emergent behavior with these features that is completely unexpected, and we wouldn't find out about it without having it there. I don't think that is a good idea. As attribute as they are defined agglomerate in a tuple, without correct typing, it is impossible to determine for a piece of code which attributes belongs to the current processing or not. For instance, let say that I'm writing a lib using attributes. I expect int attribute to be attached to a symbol and does some processing on it. If another dev of another lib decide to do the same, then it is is now impossible to use both libs together. Unless we decide up front, by convention, what an int attribute means. But even in this case, it is risky. As my experience shown in the past, using convention to ensure certain property in the some code usually fail. Yes, I know it's a risk. (And it was a no-brainer to restrict the exception types. But one must be careful in drawing analogies in programming, as different things are, well, different and can be different in unexpected, surprising ways.)
Re: User Defined Attributes
Le 07/11/2012 10:13, Timon Gehr a écrit :
On 11/07/2012 08:08 AM, Daniel Murphy wrote:
Walter Bright newshou...@digitalmars.com wrote in message
news:k7cko9$hes$1...@digitalmars.com...
On 11/6/2012 6:10 PM, Daniel Murphy wrote:
My thoughts exactly. It reminds me of the horror of C++ exceptions. I
think it would be reasonable to require every annotation is a struct or
class.
Good analogy. But I'm not sure at this point if that is the right
thing to
do.
I don't know if it will turn out to be useful either. But if it's left in
there, right or wrong, people will use it and it will be impossible to
remove later.
If two libraries both use string literal annotations for metadata (and
they
will) you can no longer use both on the same declaration at once. This
leads back to C/C++'s global namespace.
As an example:
[3] class Blah {}
What on earth is 3? Why would you want to attach 3 to a class
declaration?
How many different ways are there for libraries to interpret this?
Most importantly, if users still want to experiment with anonymous
annotations, they still can:
[tuple(3)] class Blah {}
Then what does this particular restriction buy?
Adding speculative features with no use case in mind is a recipe for
disaster.
Much like how you can use extern(C) to force global visibility, you can
still get the less hygienic behaviour, if you explicitly ask for it.
We lose nothing. If it turns out this was the wrong call, built-in types
can be restored without breaking a single line of code.
That is never a given in D.
static assert(!is(typeof({struct S{ [2] int x; }})));
I'd argue that is expression is the problem here, not really the annotation.
Re: User Defined Attributes
Le 07/11/2012 09:23, Don Clugston a écrit : If you mean, we should be working on getting the existing stuff working before we think about adding more stuff, I agree 100%. That is a good part of my point. The other part being that surprise feature dropped in master, not only impair stability, but also impair the ability for developing tooling around D. My problem isn't the feature itself. I'm all for annotation. But the way it is added in the language make nonsense and is even dangerous for D. I would say we're about three years away from it being sensible to work on annotations. It's reasonable to draft a preliminary proposal (A roadmap, what a novel concept!). But I think it would be a big mistake to do much work on it. Exactly. And propose the feature in an experimental branch or something before pushing it to master, so people can test it, it can be refined as needed and 3rd party tool can adapt to it.
Re: User Defined Attributes
Timon Gehr timon.g...@gmx.ch wrote in message
news:k7d8n1$1o69$1...@digitalmars.com...
Most importantly, if users still want to experiment with anonymous
annotations, they still can:
[tuple(3)] class Blah {}
Then what does this particular restriction buy?
It makes it harder to do the wrong thing.
Re: User Defined Attributes
Le 07/11/2012 21:35, Walter Bright a écrit :
On 11/7/2012 4:01 AM, Jacob Carlborg wrote:
I start to more and more think it would be better to explicitly
require the
developer to declare an attribute, like:
attribute foo
{
string name;
}
@foo(asd) int a;
Adding a whole new aggregate type is a pretty intrusive and major change.
So let's defined in object.d the following :
@attribute struct attribute {}
And then mark as @attribute anything that may used as attribute.
@attribute struct foo {
string name;
}
@foo(asd) int a;
If wasn't marked as @attribute, it wouldn't be an valid attribute.
Re: User Defined Attributes
On 11/7/2012 4:01 AM, Jacob Carlborg wrote:
I start to more and more think it would be better to explicitly require the
developer to declare an attribute, like:
attribute foo
{
string name;
}
@foo(asd) int a;
Adding a whole new aggregate type is a pretty intrusive and major change.
Re: User Defined Attributes
On 11/7/2012 3:05 AM, Leandro Lucarella wrote: For me the analogy with Exceptions is pretty good. The issues an conveniences of throwing anything or annotating a symbol with anything instead of just type are pretty much the same. That's a good point, I just want to wryly remark on the consistency argument that UDAs should work everywhere, but the inconsistency argument that they should not work for basic types :-) I only see functions making sense to be accepted as annotations too (that's what Python do with annotations, @annotation symbol is the same as symbol = annotation(symbol), but is quite a different language). Just functions? I thought one big use of UDAs was to mark classes as serializable.
Re: User Defined Attributes
On 2012-11-07 21:41, Walter Bright wrote: Just functions? I thought one big use of UDAs was to mark classes as serializable. Exactly, the more we can annotated the better :) -- /Jacob Carlborg
Re: User Defined Attributes
On 2012-11-07 21:38, deadalnix wrote:
Adding a whole new aggregate type is a pretty intrusive and major change.
Is it? Just have it behave as a struct or class. But I guess the
suggestion below is just as good.
So let's defined in object.d the following :
@attribute struct attribute {}
And then mark as @attribute anything that may used as attribute.
@attribute struct foo {
string name;
}
@foo(asd) int a;
If wasn't marked as @attribute, it wouldn't be an valid attribute.
I would be happy with this approach as well. But how much difference
would it actually be to have:
attribute foo {
string name;
}
--
/Jacob Carlborg
Re: User Defined Attributes
First of all: Awesome. Secondly: Fastest-growing thread ever? ;)
Re: User Defined Attributes
On Wednesday, November 07, 2012 16:45:20 Nick Sabalausky wrote: First of all: Awesome. Secondly: Fastest-growing thread ever? ;) In Announce? Probably. In all of the D groups? Probably not. There have been some _very_ active threads in the main newsgroup. This thread is quite tame in comparison to a number of them. It _is_ very active though. - Jonathan M Davis
Re: User Defined Attributes
On 11/7/2012 3:05 AM, Leandro Lucarella wrote: OK, that's another thing. And maybe a reason for listening to people having more experience with UDAs than you. For me the analogy with Exceptions is pretty good. The issues an conveniences of throwing anything or annotating a symbol with anything instead of just type are pretty much the same. I only see functions making sense to be accepted as annotations too (that's what Python do with annotations, @annotation symbol is the same as symbol = annotation(symbol), but is quite a different language). There's another aspect to this. D's UDAs are a purely compile time system, attaching arbitrary metadata to specific symbols. The other UDA systems I'm aware of appear to be runtime systems. This implies the use cases will be different - how, I don't really know. But I don't know of any other compile time UDA system. Experience with runtime systems may not be as applicable. Another interesting data point is CTFE. C++11 has CTFE, but it was deliberately crippled and burdened with constexpr. From what I read, this was out of fear that it would turn out to be an overused and overabused feature. Of course, this turned out to be a large error. One last thing. Sure, string attributes can (and surely would be) used for different purposes in different libraries. The presumption is that this would cause a conflict. But would it? There are two aspects to a UDA - the attribute itself, and the symbol it is attached to. In order to get the UDA for a symbol, one has to look up the symbol. There isn't a global repository of symbols in D. You'd have to say I want to look in module X for symbols. Why would you look in module X for an attribute that you have no reason to believe applies to symbols from X? How would an attribute for module X's symbols leak out of X on their own? It's not quite analogous to exceptions, because arbitrary exceptions thrown from module X can flow through your code even though you have no idea module X even exists.
Re: User Defined Attributes
On 11/7/2012 1:45 PM, Nick Sabalausky wrote: First of all: Awesome. Secondly: Fastest-growing thread ever? ;) The historical UDA threads have been large, too.
Re: User Defined Attributes
Le 07/11/2012 23:20, Walter Bright a écrit : On 11/7/2012 3:05 AM, Leandro Lucarella wrote: OK, that's another thing. And maybe a reason for listening to people having more experience with UDAs than you. For me the analogy with Exceptions is pretty good. The issues an conveniences of throwing anything or annotating a symbol with anything instead of just type are pretty much the same. I only see functions making sense to be accepted as annotations too (that's what Python do with annotations, @annotation symbol is the same as symbol = annotation(symbol), but is quite a different language). There's another aspect to this. D's UDAs are a purely compile time system, attaching arbitrary metadata to specific symbols. The other UDA systems I'm aware of appear to be runtime systems. This implies the use cases will be different - how, I don't really know. But I don't know of any other compile time UDA system. Experience with runtime systems may not be as applicable. Java is mostly compile time (and optionally runtime). See http://projectlombok.org/ for what can be done at compile time with attributes + compiler hooks. Another interesting data point is CTFE. C++11 has CTFE, but it was deliberately crippled and burdened with constexpr. From what I read, this was out of fear that it would turn out to be an overused and overabused feature. Of course, this turned out to be a large error. One last thing. Sure, string attributes can (and surely would be) used for different purposes in different libraries. The presumption is that this would cause a conflict. But would it? There are two aspects to a UDA - the attribute itself, and the symbol it is attached to. In order to get the UDA for a symbol, one has to look up the symbol. There isn't a global repository of symbols in D. You'd have to say I want to look in module X for symbols. Why would you look in module X for an attribute that you have no reason to believe applies to symbols from X? How would an attribute for module X's symbols leak out of X on their own? It's not quite analogous to exceptions, because arbitrary exceptions thrown from module X can flow through your code even though you have no idea module X even exists.
Re: User Defined Attributes
Awesome. Lack of UDA has really caused some very ugly workarounds in my code, and it's really nice to see that it's being solved now. Probably one of the most important missing features I've encountered. I do agree however with preventing any built-in types / literals being used as an annotation. It's just not safe, completely goes around the module system, and is abused in the same way as it would be with C++ exceptions. In C# for example, all attributes are classes derived from Attribute. This makes things a bit more obvious, allows a common base type (probably not needed in D because it's done at compile-time), but is rather hackish in my opinion (plus, in D you may want structs as attributes?). I definitely would like to see something like the @attribute suggestion though. Using types not meant to be used as attributes as attributes is dangerous and leads to conflicts when people want it to mean different things. What does '@Vector3f(1, 1, 1) int a' even mean? What if people use it to mean different things? It's just as confusing as '@3 int a'.
Re: User Defined Attributes
On 11/7/2012 2:40 PM, deadalnix wrote: Java is mostly compile time (and optionally runtime). See http://projectlombok.org/ for what can be done at compile time with attributes + compiler hooks. Doesn't putting compiler hooks in for them make them inherently global?
Re: User Defined Attributes
On 11/7/2012 3:06 PM, Kapps wrote: I do agree however with preventing any built-in types / literals being used as an annotation. It's just not safe, completely goes around the module system, and is abused in the same way as it would be with C++ exceptions. In C# for example, all attributes are classes derived from Attribute. This makes things a bit more obvious, allows a common base type (probably not needed in D because it's done at compile-time), but is rather hackish in my opinion (plus, in D you may want structs as attributes?). I definitely would like to see something like the @attribute suggestion though. Using types not meant to be used as attributes as attributes is dangerous and leads to conflicts when people want it to mean different things. What does '@Vector3f(1, 1, 1) int a' even mean? What if people use it to mean different things? It's just as confusing as '@3 int a'. See new thread I started on this in digitalmars.D.
Re: User Defined Attributes
started a new thread on this over in digitalmars.D
Re: User Defined Attributes
On Wednesday, 7 November 2012 at 23:17:24 UTC, Walter Bright
wrote:
Doesn't putting compiler hooks in for them make them inherently
global?
One of the previous threads put forth something like this:
template MyAttribute(alias subject, T... arguments) { /* some
implementation */
The attribute is a template that replaces the declaration. So you
type:
[MyAttribute(foo)]
class Something {}
And the compiler rewrites that to:
class __anonymous_Something {}
alias Something = MyAttribute!(__anonymous_Something, foo);
... or something like that. I'm going off memory here. But then
you can use the template to do whatever you'd normally do with a
template.
For some reason this feels incomplete to me. I know one of those
proposals enabled something we can't really do now, whereas what
I described here of course *can* be done now.
Re: User Defined Attributes
Le 08/11/2012 00:17, Walter Bright a écrit : On 11/7/2012 2:40 PM, deadalnix wrote: Java is mostly compile time (and optionally runtime). See http://projectlombok.org/ for what can be done at compile time with attributes + compiler hooks. Doesn't putting compiler hooks in for them make them inherently global? The hook is associated to a given attribute so no it doesn't.
Re: User Defined Attributes
On 11/7/2012 4:12 PM, deadalnix wrote: Le 08/11/2012 00:17, Walter Bright a écrit : On 11/7/2012 2:40 PM, deadalnix wrote: Java is mostly compile time (and optionally runtime). See http://projectlombok.org/ for what can be done at compile time with attributes + compiler hooks. Doesn't putting compiler hooks in for them make them inherently global? The hook is associated to a given attribute so no it doesn't. Yes, that makes the attribute global.
Re: User Defined Attributes
On 2012-11-08 02:49, Walter Bright wrote: Yes, that makes the attribute global. I don't actually know how this works in Java but if you are forced to use the fully qualified name for the attribute it won't make the attribute global. -- /Jacob Carlborg
Re: User Defined Attributes
On 2012-11-08 00:43, Adam D. Ruppe wrote:
One of the previous threads put forth something like this:
template MyAttribute(alias subject, T... arguments) { /* some
implementation */
The attribute is a template that replaces the declaration. So you type:
[MyAttribute(foo)]
class Something {}
And the compiler rewrites that to:
class __anonymous_Something {}
alias Something = MyAttribute!(__anonymous_Something, foo);
... or something like that. I'm going off memory here. But then you can
use the template to do whatever you'd normally do with a template.
For some reason this feels incomplete to me. I know one of those
proposals enabled something we can't really do now, whereas what I
described here of course *can* be done now.
Seems like a poor man's replacement for macro annotations:
http://scalamacros.org/future.html
--
/Jacob Carlborg
Re: User Defined Attributes
On Tuesday, 6 November 2012 at 07:55:51 UTC, Walter Bright wrote: References: http://www.digitalmars.com/d/archives/digitalmars/D/Custom_attributes_again_163042.html http://www.digitalmars.com/d/archives/digitalmars/D/custom_attribute_proposal_yeah_another_one_163246.html Inspired by a gallon of coffee, I decided to get it implemented. It's simple, based on what D already does (CTFE [*drool*, totally perfect awesomeness] Thanks!
Re: User Defined Attributes
Wow, that's a surprise! Just yesterday I was thinking that it would be really nice to have them for a piece of code ;) But shouldn't we keep the syntax closer to normal attributes and other languages(*)? I see a lot of arguments for doing that, with the only counter-argument that they would be in the same namespace as the built-in attributes (which should not be that bad, as this is very low level language stuff). (*) i.e. @mytype or @(string) and without the '[]'
Re: User Defined Attributes
On 11/6/2012 12:15 AM, Tove wrote: [*drool*, totally perfect awesomeness] Thanks! The neato thing is I realized I could just connect the dots on what D already does well - CTFE, tuples, and templates. The actual features can now be added by library routines.
Re: User Defined Attributes
On 11/6/2012 12:20 AM, Sönke Ludwig wrote: But shouldn't we keep the syntax closer to normal attributes and other languages(*)? I see a lot of arguments for doing that, with the only counter-argument that they would be in the same namespace as the built-in attributes (which should not be that bad, as this is very low level language stuff). (*) i.e. @mytype or @(string) and without the '[]' We can debate the syntax. I don't have a store set by this one. I was more interested in getting the semantics right. Anyhow, it's nice to have a working prototype to experiment with rather than a paper airplane.
Re: User Defined Attributes
On 11/6/2012 12:39 AM, Jakob Ovrum wrote: On Tuesday, 6 November 2012 at 07:55:51 UTC, Walter Bright wrote: -snip- It doesn't look like it would be possible to schedule any runtime code using this, meaning they're not usable for stuff like registering types for serialization support, or doing runtime linking when attached to a function pointer, etc. Since D allows one to inquire and get a list of symbols, one can then iterate over them at compile time to determine which are serializable (or have some other specific attribute).
Re: User Defined Attributes
On Tuesday, 6 November 2012 at 08:42:44 UTC, Walter Bright wrote: Since D allows one to inquire and get a list of symbols, one can then iterate over them at compile time to determine which are serializable (or have some other specific attribute). Yes, but somewhere you have to put startup code pointing in the general direction of where the attributes are used (like a module), it's not automatic. A static constructor cannot be used because it has no idea where to look. But, I yield until someone comes up with actual examples of how these UDAs are useful, because I can't think of anything interesting at the moment. I guess I should go read over the old discussions you linked (I remember participating, but can't remember any specifics).
Re: User Defined Attributes
On Tuesday, 6 November 2012 at 07:55:51 UTC, Walter Bright wrote: snip Nice to hear because it was unexpected and was requested prevously by community.
Re: User Defined Attributes
On 11/6/2012 12:42 AM, Walter Bright wrote: Since D allows one to inquire and get a list of symbols, one can then iterate over them at compile time to determine which are serializable (or have some other specific attribute). To emphasize, the User Defined Attributes thing is completely a compile time feature. However, a user defined runtime system can be built on top of it. It gives the best of both worlds.
Re: User Defined Attributes
Am 06.11.2012 09:26, schrieb Walter Bright: On 11/6/2012 12:20 AM, Sönke Ludwig wrote: But shouldn't we keep the syntax closer to normal attributes and other languages(*)? I see a lot of arguments for doing that, with the only counter-argument that they would be in the same namespace as the built-in attributes (which should not be that bad, as this is very low level language stuff). (*) i.e. @mytype or @(string) and without the '[]' We can debate the syntax. I don't have a store set by this one. I was more interested in getting the semantics right. Anyhow, it's nice to have a working prototype to experiment with rather than a paper airplane. Definitely! Thanks a lot for tackling this, to me this seems like something that can get a real killer feature for the language!
Re: User Defined Attributes
On Tuesday, 6 November 2012 at 08:39:47 UTC, Jakob Ovrum wrote: On Tuesday, 6 November 2012 at 07:55:51 UTC, Walter Bright wrote: -snip- It doesn't look like it would be possible to schedule any runtime code using this, meaning they're not usable for stuff like registering types for serialization support, or doing runtime linking when attached to a function pointer, etc. Runtime arrtibutes can be implemented as properties in object.d. This would work for classes only and for other types it can be implemented manually. Runtime attributes require substantial amount of work, introducing bugs, bloating ABI and new questions about how this feature does work with others.
Re: User Defined Attributes
On Tuesday, 6 November 2012 at 08:50:32 UTC, Walter Bright wrote:
To emphasize, the User Defined Attributes thing is completely a
compile time feature. However, a user defined runtime system
can be built on top of it.
It gives the best of both worlds.
Problem is that there's no way to do this without having the user
specify which modules it should work for, like:
import attributes;
import a, b, c;
static this() // This code cannot be automated.
{
initAttributes!a();
initAttributes!b();
initAttributes!c();
}
Re: User Defined Attributes
Am 06.11.2012 09:49, schrieb Jakob Ovrum: But, I yield until someone comes up with actual examples of how these UDAs are useful, because I can't think of anything interesting at the moment. I guess I should go read over the old discussions you linked (I remember participating, but can't remember any specifics). you're just to deep catched in the .Net-Everything-Is-Done-In-Runtime-Paradigm - thats all :) most of the stuff .Net does in runtime is not absolutely needed at runtime - but they need to because there is no compiletime reflection system available at all - and that trains developer to always thing in runtime-aspects - always
Re: User Defined Attributes
On Tuesday, 6 November 2012 at 08:56:26 UTC, Maxim Fomin wrote: Runtime arrtibutes can be implemented as properties in object.d. This would work for classes only and for other types it can be implemented manually. Runtime attributes require substantial amount of work, introducing bugs, bloating ABI and new questions about how this feature does work with others. I'm not suggesting runtime attributes should be part of the language, nor am I suggesting we add them to Phobos. All I'm saying is the UDA system has to be powerful enough that it *could* be implemented in a library if desired.
Re: User Defined Attributes
On Tuesday, 6 November 2012 at 08:55:06 UTC, Sönke Ludwig wrote:
Am 06.11.2012 09:26, schrieb Walter Bright:
On 11/6/2012 12:20 AM, Sönke Ludwig wrote: But shouldn't we
keep the
syntax closer to normal attributes and other
languages(*)? I see a lot of arguments for doing that, with
the only
counter-argument that they would be in the same namespace as
the
built-in attributes (which should not be that bad, as this is
very low
level language stuff).
(*) i.e. @mytype or @(string) and without the '[]'
We can debate the syntax. I don't have a store set by this
one. I was
more interested in getting the semantics right. Anyhow, it's
nice to
have a working prototype to experiment with rather than a
paper airplane.
Definitely! Thanks a lot for tackling this, to me this seems
like
something that can get a real killer feature for the language!
@test
void myUnittest()
{
}
Uh yeah, that would be awesome!
Re: User Defined Attributes
On Tuesday, 6 November 2012 at 09:03:49 UTC, dennis luehring wrote: you're just to deep catched in the .Net-Everything-Is-Done-In-Runtime-Paradigm - thats all :) No.
Re: User Defined Attributes
n 11/6/2012 12:59 AM, Jakob Ovrum wrote:
Problem is that there's no way to do this without having the user specify
which
modules it should work for, like:
import attributes;
import a, b, c;
static this() // This code cannot be automated.
{
initAttributes!a();
initAttributes!b();
initAttributes!c();
}
Is that really a problem?
