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
digitalmars-d-announce@puremagic.com wrote:
http://ddili.org/ders/d.en/templates_more.html
there is a little bug: opSlice(size_t, size_t) description
On Thu, 11 Sep 2014 11:48:26 -0700
Ali Çehreli via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com 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. ;-)
On 8/29/14, Andrei Alexandrescu via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com 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
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.
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
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
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
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 ;)
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.
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
digitalmars-d-announce@puremagic.com wrote:
* Formatted element output with %( and %)
by the way, i never knows about this feature. maybe i should RTFM
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
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
On Tue, 26 Aug 2014 23:16:14 -0700
Ali Çehreli via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com 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
On Tue, 26 Aug 2014 23:16:14 -0700
Ali Çehreli via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com 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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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...
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
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
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
.. 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
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
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
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
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
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,
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,
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,
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
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
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
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,
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.
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
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
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
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
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
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
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
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
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
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
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
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
On Thursday, 8 November 2012 at 09:08:23 UTC, Max Samukha wrote:
alias getAttribute!(b, foo) t;
Ignore that line.
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
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
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
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
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
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
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)); =
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
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
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.
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
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
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
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
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.
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
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
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++
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,
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
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
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.
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
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
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 {}
First of all: Awesome.
Secondly: Fastest-growing thread ever? ;)
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
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
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.
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
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
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?
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
started a new thread on this over in digitalmars.D
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
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
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
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
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 {}
Attributes
---
User Defined Attributes (UDA) are compile time expressions that can be attached
to a declaration. These attributes can then be queried, extracted, and
manipulated
at compile time. There is no runtime component to them.
Grammatically, a UDA is a StorageClass
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
1 - 100 of 216 matches
Mail list logo