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
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
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
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 {
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 {}
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
Wow, that's a surprise! Just yesterday I was thinking that it would be
really nice to have them for a piece of code ;)
But shouldn't we keep the syntax closer to normal attributes and other
languages(*)? I see a lot of arguments for doing that, with the only
counter-argument that they would be in
On 11/6/2012 12:15 AM, Tove wrote:
[*drool*, totally perfect awesomeness] Thanks!
The neato thing is I realized I could just connect the dots on what D already
does well - CTFE, tuples, and templates. The actual features can now be added by
library routines.
On 11/6/2012 12:20 AM, Sönke Ludwig wrote: But shouldn't we keep the syntax
closer to normal attributes and other
languages(*)? I see a lot of arguments for doing that, with the only
counter-argument that they would be in the same namespace as the
built-in attributes (which should not be that
On 11/6/2012 12:39 AM, Jakob Ovrum wrote: On Tuesday, 6 November 2012 at
07:55:51 UTC, Walter Bright wrote:
-snip-
It doesn't look like it would be possible to schedule any runtime code using
this, meaning they're not usable for stuff like registering types for
serialization support, or
On Tuesday, 6 November 2012 at 08:42:44 UTC, Walter Bright wrote:
Since D allows one to inquire and get a list of symbols, one
can then iterate over them at compile time to determine which
are serializable (or have some other specific attribute).
Yes, but somewhere you have to put startup
On Tuesday, 6 November 2012 at 07:55:51 UTC, Walter Bright wrote:
snip
Nice to hear because it was unexpected and was requested
prevously by community.
On 11/6/2012 12:42 AM, Walter Bright wrote:
Since D allows one to inquire and get a list of symbols, one can then iterate
over them at compile time to determine which are serializable (or have some
other specific attribute).
To emphasize, the User Defined Attributes thing is completely a
Am 06.11.2012 09:26, schrieb Walter Bright:
On 11/6/2012 12:20 AM, Sönke Ludwig wrote: But shouldn't we keep the
syntax closer to normal attributes and other
languages(*)? I see a lot of arguments for doing that, with the only
counter-argument that they would be in the same namespace as the
On Tuesday, 6 November 2012 at 08:39:47 UTC, Jakob Ovrum wrote:
On Tuesday, 6 November 2012 at 07:55:51 UTC, Walter Bright
wrote:
-snip-
It doesn't look like it would be possible to schedule any
runtime code using this, meaning they're not usable for stuff
like registering types for
On Tuesday, 6 November 2012 at 08:50:32 UTC, Walter Bright wrote:
To emphasize, the User Defined Attributes thing is completely a
compile time feature. However, a user defined runtime system
can be built on top of it.
It gives the best of both worlds.
Problem is that there's no way to do
Am 06.11.2012 09:49, schrieb Jakob Ovrum:
But, I yield until someone comes up with actual examples of how
these UDAs are useful, because I can't think of anything
interesting at the moment. I guess I should go read over the old
discussions you linked (I remember participating, but can't
On Tuesday, 6 November 2012 at 08:56:26 UTC, Maxim Fomin wrote:
Runtime arrtibutes can be implemented as properties in
object.d. This would work for classes only and for other types
it can be implemented manually. Runtime attributes require
substantial amount of work, introducing bugs,
On Tuesday, 6 November 2012 at 08:55:06 UTC, Sönke Ludwig wrote:
Am 06.11.2012 09:26, schrieb Walter Bright:
On 11/6/2012 12:20 AM, Sönke Ludwig wrote: But shouldn't we
keep the
syntax closer to normal attributes and other
languages(*)? I see a lot of arguments for doing that, with
the only
On Tuesday, 6 November 2012 at 09:03:49 UTC, dennis luehring
wrote:
you're just to deep catched in the
.Net-Everything-Is-Done-In-Runtime-Paradigm - thats all :)
No.
n 11/6/2012 12:59 AM, Jakob Ovrum wrote:
Problem is that there's no way to do this without having the user specify
which
modules it should work for, like:
import attributes;
import a, b, c;
static this() // This code cannot be automated.
{
initAttributes!a();
1 - 100 of 201 matches
Mail list logo
