Re: "Programming in D" book, "User Defined Attributes (UDA)" chapter
On Thu, 11 Sep 2014 11:48:26 -0700 Ali Çehreli via Digitalmars-d-announce wrote: > Would you like to send me your name so that I add it to the > Acknowledgments section. (Otherwise ketmar is it. :) Ketmar, or Ketmar Dark if you want "full name". ;-) signature.asc Description: PGP signature
Re: "Programming in D" book, "User Defined Attributes (UDA)" chapter
On 09/11/2014 11:30 AM, ketmar via Digitalmars-d-announce wrote: On Thu, 11 Sep 2014 10:47:40 -0700 Ali Çehreli via Digitalmars-d-announce wrote: http://ddili.org/ders/d.en/templates_more.html there is a little bug: opSlice(size_t, size_t) description is: `collection[i, j]` shouldn't it be: `collection[i..j]`? Thank you. There are others in the other table as well. Fix is coming soon. I have already fixed the template constaint bugs: Two of them should be if (dimension <= 1) (not 2). Would you like to send me your name so that I add it to the Acknowledgments section. (Otherwise ketmar is it. :) Ali
Re: "Programming in D" book, "User Defined Attributes (UDA)" chapter
On Thu, 11 Sep 2014 10:47:40 -0700 Ali Çehreli via Digitalmars-d-announce wrote: >http://ddili.org/ders/d.en/templates_more.html there is a little bug: opSlice(size_t, size_t) description is: `collection[i, j]` shouldn't it be: `collection[i..j]`? signature.asc Description: PGP signature
Re: "Programming in D" book, "User Defined Attributes (UDA)" chapter
On 09/10/2014 01:41 AM, Andrej Mitrovic via Digitalmars-d-announce wrote: > If you do consider publishing the book, do let us know before it > happens so those of us who want to can go through a thorough review > and let you know of any typo's or mistakes before it's set in stone > (or on paper :P). I'd be glad to review it in-depth. That is very kind of you. Everybody is always welcome to do so. :) I guess putting the sources on a git repo would help the reviewers. There was such a request at some point but I did not follow up on that. Ali
Re: "Programming in D" book, "User Defined Attributes (UDA)" chapter
On 09/09/2014 05:04 PM, Ali Çehreli wrote: > I have already tied many loose ends. I am currently > changing the operator overloading chapter to include the more proper > multi-dimensional indexing and slicing that came with 2.066. Done. I divided array operator overloading (indexing and slicing) into two categories: 1) I updated the existing Operator Overloading chapter to cover only single-dimensional uses by - opIndex - opIndexAssign - opIndexUnary - opIndexOpAssign - opDollar - opSlice (I specifically took out the now-discouraged opSliceUnary, opSliceAssign, and opSliceOpAssign.) http://ddili.org/ders/d.en/operator_overloading.html (Chuck Allison will be mad at me because I used one of his programming assignments as an example there: Double-ended queue implemented in terms of two D slices. :) ) 2) I added the multi-dimensional operator overloading to the More Templates chapter under the section "Using templates in multi-dimensional operator overloading". (That is admittedly a curious place for it but multi-dimensional operator overloading uses tuple template parameters, which are introduced in that chapter.) There, I especially noted that the responsibility of opSlice is reduced to returning simply a Tuple!(size_t, size_t) or an equivalent type. (In case others have missed it, returning a slice representing all of the elements of a container is now the responsibility of opIndex that takes no parameters.) http://ddili.org/ders/d.en/templates_more.html Ali
Re: "Programming in D" book, "User Defined Attributes (UDA)" chapter
On 8/29/14, Andrei Alexandrescu via Digitalmars-d-announce wrote: > Awesome!! Put it on Amazon too! -- Andrei Yeah, I'd be the first in line to buy it as well! If you do consider publishing the book, do let us know before it happens so those of us who want to can go through a thorough review and let you know of any typo's or mistakes before it's set in stone (or on paper :P). I'd be glad to review it in-depth.
Re: "Programming in D" book, "User Defined Attributes (UDA)" chapter
On 09/09/2014 04:38 PM, Olivier Henley wrote: > Blurb has a number of pages limitation that would require a two volumes > release of your book. :/ Lulu can make it to 740 pages. CreateSpace > offers packages up to 828 pages. Page count can change simply by changing the font size. ;) > I found this post interesting: > http://www.cnet.com/news/self-publishing-a-book-25-things-you-need-to-know/ Thank you. I had read that before and I have it bookmarked to be read again. > Otherwise did you contact any publisher? My only contact was in 2011 with Addison Wesley through Andrei. He had relayed my interest to his editor and had learned that "the field of general programming introduction is very crowded." They and other publishers may think differently as the book has become a little more like a language reference as well. As an update, I have already tied many loose ends. I am currently changing the operator overloading chapter to include the more proper multi-dimensional indexing and slicing that came with 2.066. Ali
Re: "Programming in D" book, "User Defined Attributes (UDA)" chapter
On Friday, 29 August 2014 at 05:35:12 UTC, Ali Çehreli wrote: Would you recommend considering at least some of Blurb.com's competitors as well? Who? Right. Blurb has a number of pages limitation that would require a two volumes release of your book. :/ Lulu can make it to 740 pages. CreateSpace offers packages up to 828 pages. Both can distribute through Amazon. Prices are somewhat similar... I found this post interesting: http://www.cnet.com/news/self-publishing-a-book-25-things-you-need-to-know/ Otherwise did you contact any publisher? olivier
Re: "Programming in D" book, "User Defined Attributes (UDA)" chapter
On 8/29/14, 6:30 AM, Ali Çehreli wrote: On 08/29/2014 03:45 AM, Dejan Lekic wrote: Do you by any chance plan to release ePub version of it? Yes. It will happen. :) Ali Awesome!! Put it on Amazon too! -- Andrei
Re: "Programming in D" book, "User Defined Attributes (UDA)" chapter
On 08/29/2014 03:45 AM, Dejan Lekic wrote: Do you by any chance plan to release ePub version of it? Yes. It will happen. :) Ali
Re: "Programming in D" book, "User Defined Attributes (UDA)" chapter
On Wednesday, 27 August 2014 at 06:16:14 UTC, Ali Çehreli wrote: I made some additions and corrections. The following are the major ones: * The 'User Defined Attributes (UDA)' chapter * @nogc * foreach_reverse * Formatted element output with %( and %) * static this, static ~this, shared static this, and shared static ~this As a reminder, the book is available as PDF, downloadable from the header of each chapter: http://ddili.org/ders/d.en/index.html Ali Good work Ali! Do you by any chance plan to release ePub version of it?
Re: "Programming in D" book, "User Defined Attributes (UDA)" chapter
On 08/28/2014 02:06 PM, Olivier Henley wrote: > Huge thx for all the nice work btw. I thank everyone for the nice words and the motivation. :) > 1. Does the book have been entirely translated then..? Technically yes, but UDAs had to be added before I could call it complete and there are still missing pieces: - opDollar and the very recent multi-index opSlice - @disable - Importing multiple modules of a package - This is an interesting one, which I think not many people know about: aliases for operator overloading. See the following push for an example: https://github.com/D-Programming-Language/dmd/pull/989/files - Table of contents for the pdf version - Book index - A number of other things > 2. Would you agree to configure a print version through Blurb.com? This > way we could get a copy through amazon like ... tomorrow ;) I think I am finally very close to doing that, but not today. :) Would you recommend considering at least some of Blurb.com's competitors as well? Who? Thank you, Ali
Re: "Programming in D" book, "User Defined Attributes (UDA)" chapter
On 08/26/2014 11:42 PM, ketmar via Digitalmars-d-announce wrote: On Tue, 26 Aug 2014 23:16:14 -0700 Ali Çehreli via Digitalmars-d-announce wrote: * Formatted element output with %( and %) by the way, i never knows about this feature. maybe i should RTFM someday... They appear under formattedWrite: http://dlang.org/phobos/std_format.html#.formattedWrite My brief explanation is under "Formatted element output" here: http://ddili.org/ders/d.en/formatted_output.html Ali
Re: "Programming in D" book, "User Defined Attributes (UDA)" chapter
On Thursday, 28 August 2014 at 21:07:00 UTC, Olivier Henley wrote: Super! Huge thx for all the nice work btw. Questions: 1. Does the book have been entirely translated then..? Here, the answer is "Yes" Ali's work is impressive.
Re: "Programming in D" book, "User Defined Attributes (UDA)" chapter
Super! Huge thx for all the nice work btw. Questions: 1. Does the book have been entirely translated then..? 2. Would you agree to configure a print version through Blurb.com? This way we could get a copy through amazon like ... tomorrow ;)
Re: "Programming in D" book, "User Defined Attributes (UDA)" chapter
On Wednesday, 27 August 2014 at 06:16:14 UTC, Ali Çehreli wrote: I made some additions and corrections. The following are the major ones: * The 'User Defined Attributes (UDA)' chapter * @nogc * foreach_reverse * Formatted element output with %( and %) * static this, static ~this, shared static this, and shared static ~this Wonderful work. Many thanks.
Re: "Programming in D" book, "User Defined Attributes (UDA)" chapter
On Tue, 26 Aug 2014 23:16:14 -0700 Ali Çehreli via Digitalmars-d-announce wrote: > * Formatted element output with %( and %) by the way, i never knows about this feature. maybe i should RTFM someday... signature.asc Description: PGP signature
Re: "Programming in D" book, "User Defined Attributes (UDA)" chapter
On Tue, 26 Aug 2014 23:16:14 -0700 Ali Çehreli via Digitalmars-d-announce wrote: > * The 'User Defined Attributes (UDA)' chapter great! > * static this, static ~this, shared static this, and shared static > ~this and this too. signature.asc Description: PGP signature
"Programming in D" book, "User Defined Attributes (UDA)" chapter
I made some additions and corrections. The following are the major ones: * The 'User Defined Attributes (UDA)' chapter * @nogc * foreach_reverse * Formatted element output with %( and %) * static this, static ~this, shared static this, and shared static ~this As a reminder, the book is available as PDF, downloadable from the header of each chapter: http://ddili.org/ders/d.en/index.html Ali
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 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 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 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
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 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
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 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 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
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 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
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 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 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/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 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/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
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 2012-11-14 14:28, 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 ... That doesn't sound like a very good idea. I think it's better to not use raw ints. -- /Jacob Carlborg
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
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 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 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 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
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 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
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-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
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
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
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
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 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
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/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
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
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
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
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 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
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
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 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-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 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 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 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 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 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 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 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 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 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/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 07:35:30 UTC, Jacob Carlborg
wrote:
On 2012-11-07 23:20, Walter Bright wrote:
module bar;
@attribute struct foo
{
string name;
}
@foo int a;
alias Tuple!(__traits(getAttributes, foo)) TP;
enum bool yes = hasAttribute!(bar.foo);
static if (yes)
enum foo attr = getAttribute!(bar.foo);
The last two could actually be library functions.
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):
// library that defines attribute accessors
module library;
import std.typetuple;
template TypeOf(alias symbol)
{
alias typeof(symbol) TypeOf;
}
template indexOfAttribute(alias symbol, alias attrType)
{
alias staticMap!(TypeOf, __traits(getAttributes, symbol))
attrTypes;
enum indexOfAttribute = staticIndexOf!(attrTypes, attrType);
}
template hasAttribute(alias symbol, alias attrType)
{
enum hasAttribute = indexOfAttribute!(symbol, attrType) != -1;
}
template getAttribute(alias symbol, alias attrType)
{
alias TypeTuple!(__traits(getAttributes, symbol)) attrs;
enum getAttribute = attrs[indexOfAttribute!(symbol,
attrType)];
}
// module that defines a foo attribute
module a;
struct foo
{
string name;
}
[foo("a's foo")] int a;
// an unrelated module that defines its own foo
module b;
import library;
import a;
struct foo
{
string name;
}
[foo("b's foo")] int b;
static if (hasAttribute!(b, foo))
{
alias getAttribute!(b, foo) t;
static assert(getAttribute!(b, foo).name == "b's foo");
}
static if (hasAttribute!(a.a, a.foo))
static assert(getAttribute!(a.a, a.foo).name == "a's foo");
void main()
{
}
Re: User Defined Attributes
On 2012-11-07 23:20, Walter Bright wrote:
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.
This is what I start to like less and less about the current
implementation of UDA. There is no actual attribute. There is the symbol
with a bunch of random attached values.
I want to be able to do something like this:
module bar;
@attribute struct foo
{
string name;
}
@foo int a;
alias Tuple!(__traits(getAttributes, foo)) TP;
enum bool yes = hasAttribute!(bar.foo);
static if (yes)
enum foo attr = getAttribute!(bar.foo);
The last two could actually be library functions.
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?
Have you ever heard of libraries. You can pass a symbol as an alias
parameter to a function of a completely different library.
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.
--
/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 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 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
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 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
started a new thread on this over in digitalmars.D
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
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
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
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
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
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 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
First of all: Awesome. Secondly: Fastest-growing thread ever? ;)
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
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 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 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
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
"Timon Gehr" 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 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
Le 07/11/2012 10:13, Timon Gehr a écrit :
On 11/07/2012 08:08 AM, Daniel Murphy wrote:
"Walter Bright" 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 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.)
