On 2012-03-28 03:41, Martin Nowak wrote:
Just showing this because it never comes up that one can already implement
runtime reflection using ModuleInfo.xgetMembers and
TypeInfo_Struct.xgetMembers.
module a;
import std.stdio, std.variant;
void main()
{
foreach(m; ModuleInfo)
{
if (m.name != "b"
Note that one library that did attempt runtime reflection capability
(flectioned) does all this at runtime, and does some really funky shit,
like opening /proc/self/map on Linux, or requiring you to pass an
OPTLINK map file. I don't look at these as "innovations" as much as I
do
as workarounds.
On Sunday, 25 March 2012 at 15:24:18 UTC, Jacob Carlborg wrote:
On 2012-03-22 02:23, Tove wrote:
mixin(attr(q{struct Foo
{
@NonSerialized int x;
@NonSerialized int y;
int z;
}}));
void main()
{
auto m = [ __traits(allMembers, Foo) ];
writeln("Normal members of Foo:", m);
auto n = [ __traits(a
On 2012-03-22 15:31, Artur Skawina wrote:
For run-time accessible custom attributes (if those are even necessary),
the lib solution wouldn't be much different than a built-in one anyway.
artur
Accessing the custom attributes at runtime are necessary. Serialization
is one example that could t
On 2012-03-22 08:17, Manu wrote:
By this logic, I might as well stick with C++. It's 'possible' to do
everything I need, but it makes my cry myself to sleep at night, and
wastes insane amounts of time.
Code simplicity and cleanliess on the front end IS important, it makes
code reasable, maintain
On 2012-03-22 02:23, Tove wrote:
mixin(attr(q{struct Foo
{
@NonSerialized int x;
@NonSerialized int y;
int z;
}}));
void main()
{
auto m = [ __traits(allMembers, Foo) ];
writeln("Normal members of Foo:", m);
auto n = [ __traits(allMembers, Foo_Serializable) ];
writeln("Serializable members of
On Thursday, 22 March 2012 at 23:48:03 UTC, deadalnix wrote:
Inference isn't possible with an attribute system.
It isn't possible simply because it wasn't implemented yet.
nothing prevents us to add such a feature in the future. Could be
a worthwhile enhancement for D3 or D4, given we actual
Le 22/03/2012 03:05, Andrei Alexandrescu a écrit :
On 3/21/12 6:02 PM, deadalnix wrote:
Le 21/03/2012 17:22, Andrei Alexandrescu a écrit :
On 3/21/12 11:17 AM, Timon Gehr wrote:
On 03/20/2012 10:36 PM, deadalnix wrote:
Even the propagation of pure, @safe, nothrow and const that has been
discu
On 03/21/12 14:36, Adam D. Ruppe wrote:
> On Wednesday, 21 March 2012 at 08:29:23 UTC, Tove wrote:
>> With the mixin improvement proposal any arbitrarily complex feature can be
>> implemented in the library, appearing to enjoy first class syntax with just
>> 1 extra character penalty vs the compi
On 3/22/12 2:32 AM, Andrei Alexandrescu wrote:
On 3/21/12 12:06 PM, Jacob Carlborg wrote:
On 2012-03-21 16:11, Andrei Alexandrescu wrote:
I think the liability here is that b needs to appear in two places, once
in the declaration proper and then in the NonSerialized part. (A
possible advantage
On 3/22/12, Kapps wrote:
> 1) It wrecks things that use template arguments, possibly special
> casing for certain types.
Yeah I've noticed things tend to break with alias this. Anyway if
templates could be improved for these edge-cases then it's a benefit
for everyone, regardless of annotations.
On 20/03/12 22:29, Jacob Carlborg wrote:
On 2012-03-20 17:13, Andrei Alexandrescu wrote:
On 3/20/12 10:52 AM, Jacob Carlborg wrote:
On 2012-03-20 16:17, Andrei Alexandrescu wrote:
On 3/20/12 12:50 AM, Kapps wrote:
Perhaps we should add a field of type Variant[string].
No, not Variant[stri
On Thursday, 22 March 2012 at 10:18:24 UTC, Andrej Mitrovic wrote:
On 3/21/12, Andrei Alexandrescu
wrote:
I think the liability here is that b needs to appear in two
places.
Andrei, how about this:
Note that I've had to make a constructor because I can't
implicitly
assign a string to a Non
On Thursday, 22 March 2012 at 10:18:24 UTC, Andrej Mitrovic wrote:
On 3/21/12, Andrei Alexandrescu
wrote:
I think the liability here is that b needs to appear in two
places.
Andrei, how about this:
Note that I've had to make a constructor because I can't
implicitly
assign a string to a NonS
On 3/21/12, Andrei Alexandrescu wrote:
> I think the liability here is that b needs to appear in two places.
Andrei, how about this:
import std.stdio;
import std.conv;
struct NonSerialized(T)
{
enum isNonSerialized = true;
T payload;
alias payload this;
}
struct Foo
{
this(int
On 21 March 2012 20:32, Andrei Alexandrescu
wrote:
> Well if the argument boils down to nice vs. ugly, as opposed to possible
> vs. impossible - it's quite a bit less compelling.
>
By this logic, I might as well stick with C++. It's 'possible' to do
everything I need, but it makes my cry myself t
On 3/21/12 6:02 PM, deadalnix wrote:
Le 21/03/2012 17:22, Andrei Alexandrescu a écrit :
On 3/21/12 11:17 AM, Timon Gehr wrote:
On 03/20/2012 10:36 PM, deadalnix wrote:
Even the propagation of pure, @safe, nothrow and const that has been
discussed recently can be done with that feature.
I'm
On Wednesday, 21 March 2012 at 15:11:47 UTC, Andrei Alexandrescu
wrote:
class Foo
{
int a;
int b;
mixin NonSerialized!(b);
}
I think the liability here is that b needs to appear in two
places, once in the declaration proper and then in the
NonSerialized part. (A possible advantage is that so
Le 21/03/2012 17:22, Andrei Alexandrescu a écrit :
On 3/21/12 11:17 AM, Timon Gehr wrote:
On 03/20/2012 10:36 PM, deadalnix wrote:
Even the propagation of pure, @safe, nothrow and const that has been
discussed recently can be done with that feature.
I'm sceptical. How would that work exactly
On 2012-03-21 22:32, Steven Schveighoffer wrote:
What I envision is that @makeAPoint translates to the CTFE engine
calling makeAPoint with no arguments. This returns a Point2d default
initialized. That result is stored in the TypeInfo (or ModuleInfo) in
the appropriate location for the 'x' membe
On Wed, 21 Mar 2012 17:10:06 -0400, Jacob Carlborg wrote:
On 2012-03-21 19:32, Steven Schveighoffer wrote:
In my proposal, I specified that the annotation can be applied only to
module-level functions (normal or templated), and the result of those
functions is what gets saved. So with that ca
On 2012-03-21 19:32, Steven Schveighoffer wrote:
In my proposal, I specified that the annotation can be applied only to
module-level functions (normal or templated), and the result of those
functions is what gets saved. So with that capability, you should be
able to store any CTFE-evaluatable st
On 2012-03-21 19:32, Andrei Alexandrescu wrote:
Well if the argument boils down to nice vs. ugly, as opposed to possible
vs. impossible - it's quite a bit less compelling.
No, that's just one part on the problem. Read Adam D. Ruppe's posts in
this thread, for example.
--
/Jacob Carlborg
On 2012-03-21 18:22, F i L wrote:
Jacob Carlborg wrote:
Only the name of the variables are necessary in my serialization library.
Wouldn't mixing in an enum be more useful? You could use it at compile
time that way.
I'm using a static const variable because it's compatible with D1. It
still
On 2012-03-21 17:27, F i L wrote:
I'm not sure, you're understand of D's compiler-time structures is much
better than mine. Serialization "attributes" are mostly used at runtime,
so having mixing in a static enum *should* mean reflection upon the
property at both runtime and compiletime.
I'm u
On Wed, 21 Mar 2012 13:47:56 -0400, Jacob Carlborg wrote:
On 2012-03-21 17:00, Adam D. Ruppe wrote:
The other thing is @attribute struct {} rather than just
struct {}. I don't any benefit to that. If I want to
reuse a regular, runtime struct to store info at compile
time, why shouldn't I be
On 3/21/12 12:06 PM, Jacob Carlborg wrote:
On 2012-03-21 16:11, Andrei Alexandrescu wrote:
I think the liability here is that b needs to appear in two places, once
in the declaration proper and then in the NonSerialized part. (A
possible advantage is that sometimes it may be advantageous to keep
On 2012-03-21 17:00, Adam D. Ruppe wrote:
On Wednesday, 21 March 2012 at 15:02:15 UTC, Jacob Carlborg wrote:
Here's my proposal:
Ah yes, I think I did read that before.
I'm not in love with the key=value or the explicit
@attribute on the classes, which is the two biggest
differences we have.
On Wednesday, 21 March 2012 at 17:26:19 UTC, Adam D. Ruppe wrote:
The compiler keeping a list of notes attached to the
declaration remains the only *right* way to do it.
Another note on correctness btw, this thing is wrong
if in other modules.
mixin Note!(a, q{ NotSerialized() });
that strin
On Wednesday, 21 March 2012 at 16:02:22 UTC, Andrei Alexandrescu
wrote:
Ideally the above should work, and also mixing in several
NonSerialized instances within the same type should also work.
Oh god, I feel like the spawn of Hacktan.
I'm taking the DSL identifiers to the max. Consider
the fo
Jacob Carlborg wrote:
Only the name of the variables are necessary in my
serialization library.
Wouldn't mixing in an enum be more useful? You could use it at
compile time that way.
On 2012-03-21 16:20, F i L wrote:
Andrei Alexandrescu wrote:
In case there are several non-serialized variables, how do you avoid
clashes between different definitions of __nonSerialized?
struct A {
int a, b;
mixin NonSerialized!(a, b);
}
static const __nonSerialized = ["a", "b"];
Exactly.
On 2012-03-21 16:26, F i L wrote:
Also, if where meant how could you store multiple types, you could just
use an Associative Array:
struct A {
int a;
float b;
mixin NonSerialized!(a, b);
}
static const __nonSerialized = ["int":"a", "int":"b"];
Only the name of the variables are necessary in
On 2012-03-21 16:11, Andrei Alexandrescu wrote:
I think the liability here is that b needs to appear in two places, once
in the declaration proper and then in the NonSerialized part. (A
possible advantage is that sometimes it may be advantageous to keep all
symbols with a specific attribute in on
On Wednesday, 21 March 2012 at 16:21:21 UTC, Andrei Alexandrescu
wrote:
On 3/21/12 11:15 AM, F i L wrote:
Andrei Alexandrescu wrote:
Is this implemented, or a thought?
Just a thought (I even accidentally reversed the key-value
order), but I
don't see why it couldn't work. I'll try and make
On 3/21/12 11:17 AM, Timon Gehr wrote:
On 03/20/2012 10:36 PM, deadalnix wrote:
Even the propagation of pure, @safe, nothrow and const that has been
discussed recently can be done with that feature.
I'm sceptical. How would that work exactly?
I, too, am highly skeptical. For one thing these
On 3/21/12 11:15 AM, F i L wrote:
Andrei Alexandrescu wrote:
Is this implemented, or a thought?
Just a thought (I even accidentally reversed the key-value order), but I
don't see why it couldn't work. I'll try and make up a quick
implementation.
Wouldn't a better approach rely on a compile-t
On 03/20/2012 10:36 PM, deadalnix wrote:
Even the propagation of pure, @safe, nothrow and const that has been
discussed recently can be done with that feature.
I'm sceptical. How would that work exactly?
Andrei Alexandrescu wrote:
Is this implemented, or a thought?
Just a thought (I even accidentally reversed the key-value
order), but I don't see why it couldn't work. I'll try and make
up a quick implementation.
On 3/21/12 10:26 AM, F i L wrote:
On Wednesday, 21 March 2012 at 15:20:35 UTC, F i L wrote:
Andrei Alexandrescu wrote:
In case there are several non-serialized variables, how do you avoid
clashes between different definitions of __nonSerialized?
struct A {
int a, b;
mixin NonSerialized!(a, b)
On 3/21/12 10:20 AM, F i L wrote:
Andrei Alexandrescu wrote:
In case there are several non-serialized variables, how do you avoid
clashes between different definitions of __nonSerialized?
struct A {
int a, b;
mixin NonSerialized!(a, b);
}
static const __nonSerialized = ["a", "b"];
That's ma
On Wednesday, 21 March 2012 at 15:02:15 UTC, Jacob Carlborg wrote:
Here's my proposal:
Ah yes, I think I did read that before.
I'm not in love with the key=value or the explicit
@attribute on the classes, which is the two biggest
differences we have.
The key=value is nice, but it isn't in the
static const __nonSerialized = ["int":"a", "int":"b"];
Typo, I meant: ["int":"a", "float":"b"];
On Wednesday, 21 March 2012 at 15:20:35 UTC, F i L wrote:
Andrei Alexandrescu wrote:
In case there are several non-serialized variables, how do you
avoid clashes between different definitions of __nonSerialized?
struct A {
int a, b;
mixin NonSerialized!(a, b);
}
static const __nonSerial
Andrei Alexandrescu wrote:
In case there are several non-serialized variables, how do you
avoid clashes between different definitions of __nonSerialized?
struct A {
int a, b;
mixin NonSerialized!(a, b);
}
static const __nonSerialized = ["a", "b"];
On Wednesday, 21 March 2012 at 13:54:29 UTC, Steven Schveighoffer
wrote:
I think the closest anyone has come is Jacob, with his orange
library. Maybe he can respond to this point.
I have some runtime reflection in web.d, but the way I do
it is to build up the info at startup, and there's a
spe
On 3/21/12 9:57 AM, Jacob Carlborg wrote:
On 2012-03-21 14:54, Steven Schveighoffer wrote:
On Tue, 20 Mar 2012 12:16:41 -0400, Andrei Alexandrescu
wrote:
Maybe there's a better approach than flectioned. Consider the language
is frozen solid. How would you solve problems with it?
I think the
On 2012-03-21 15:02, Adam D. Ruppe wrote:
On Wednesday, 21 March 2012 at 08:08:12 UTC, Jacob Carlborg wrote:
That's basically my initial proposal and how annotations work in Java.
Cool. I did not realize that.
Here's my proposal:
http://forum.dlang.org/thread/bccwycoexxykfgxve...@forum.dlan
On 2012-03-21 14:54, Steven Schveighoffer wrote:
On Tue, 20 Mar 2012 12:16:41 -0400, Andrei Alexandrescu
wrote:
Maybe there's a better approach than flectioned. Consider the language
is frozen solid. How would you solve problems with it?
I think the closest anyone has come is Jacob, with his
On Wednesday, 21 March 2012 at 08:08:12 UTC, Jacob Carlborg wrote:
That's basically my initial proposal and how annotations work
in Java.
Cool. I did not realize that.
On Tue, 20 Mar 2012 12:16:41 -0400, Andrei Alexandrescu
wrote:
On 3/20/12 11:09 AM, Steven Schveighoffer wrote:
On Tue, 20 Mar 2012 11:17:02 -0400, Andrei Alexandrescu
wrote:
I'm afraid I disagree. A targeted language feature definitely makes a
library approach inferior, by definition. But
On Wednesday, 21 March 2012 at 08:29:23 UTC, Tove wrote:
With the mixin improvement proposal any arbitrarily complex
feature can be implemented in the library, appearing to enjoy
first class syntax with just 1 extra character penalty vs the
compiler.
My main concern with the library implement
On Wednesday, 21 March 2012 at 08:08:12 UTC, Jacob Carlborg wrote:
On 2012-03-21 01:35, Adam D. Ruppe wrote:
On Wednesday, 21 March 2012 at 00:03:28 UTC, James Miller
wrote:
So you'd just very simply do:
struct MyAttribute { bool activated; }
// @note is just like doing internalTuple ~= MyAtt
On 2012-03-21 01:35, Adam D. Ruppe wrote:
On Wednesday, 21 March 2012 at 00:03:28 UTC, James Miller wrote:
So you'd just very simply do:
struct MyAttribute { bool activated; }
// @note is just like doing internalTuple ~= MyAttribute(true)
// and MyAttribute is of course just a plain old struct
On 2012-03-20 22:36, deadalnix wrote:
It is more tricky if the property isn't a simple attribute to read.
Again, consider what is done with this simple example :
http://projectlombok.org/
We have the opportunity here to introduce in D the concept of aspect
oriented programming. This is HUGE. If
On Wednesday, 21 March 2012 at 00:03:28 UTC, James Miller wrote:
template hasAnnotation(alias data, string an) {
enum hasAnnotation = __traits(hasAnnotation, data, an);
}
I'm actually thinking of identifying them by type. Types
are well established in the language - scoping, namespaces,
fie
Sorry for not quoting, but I'm not sure who to quote...
I think people are over-thinking this issue. Adam's initial proposal
was simply to be able to add compile-time checkable data to data
structures and functions. I think this works well at this level. As he
demonstrated, string mixins and ctfe
Le 18/03/2012 05:49, Walter Bright a écrit :
On 3/17/2012 9:12 PM, F i L wrote:
Walter Bright wrote:
I also do not get why per-instance attributes even exist, as I agree
that's
what fields are for.
Attributes are per-type (type properties, methods, etc), not
per-instance, and
only accessible
Le 20/03/2012 22:36, Andrei Alexandrescu a écrit :
On 3/20/12 4:36 PM, deadalnix wrote:
We have the opportunity here to introduce in D the concept of aspect
oriented programming. This is HUGE. If you are afraid of the addition of
a functionnality to the language, don"t worry, you are not just ad
On 3/20/12 4:36 PM, deadalnix wrote:
We have the opportunity here to introduce in D the concept of aspect
oriented programming. This is HUGE. If you are afraid of the addition of
a functionnality to the language, don"t worry, you are not just adding a
functionnality, but a whole new paradigm.
I
Le 16/03/2012 18:36, Adam D. Ruppe a écrit :
On Friday, 16 March 2012 at 16:57:26 UTC, Steven Schveighoffer wrote:
I thought @ was supposed to be a user-defined annotation.
Otherwise, why did we introduce @syntax?
idk, to "reduce" the number of keywords or somethiny.
This is why I call it a m
Le 16/03/2012 19:23, Andrej Mitrovic a écrit :
On 3/16/12, Adam D. Ruppe wrote:
The current language solution isn't really *bad* with enough
library help, but it isn't particularly *good* either and I
don't think it can be. I've tried a few things, and I still
see the lack of user annotations a
Le 16/03/2012 17:09, Andrei Alexandrescu a écrit :
On 3/16/12 8:35 AM, Adam D. Ruppe wrote:
enum Serializable { yes, no }
@note(Serializable.yes) int a;
[...]
foreach(i, exp; __traits(getNotes, a)) {
static assert(is(typeof(exp) == Serializable);
static assert(exp == Serializable.yes);
}
So
On 2012-03-20 20:17, Andrei Alexandrescu wrote:
On 3/20/12 2:04 PM, Piotr Szturmaj wrote:
Please, do not transform D into a dynamic language.
Where's the "dynamic languages rok" crowd when you need it :o).
Andrei
They left you behind after all those "d rox" comments :)
--
/Jacob Carlborg
On 2012-03-20 17:13, Andrei Alexandrescu wrote:
On 3/20/12 10:52 AM, Jacob Carlborg wrote:
On 2012-03-20 16:17, Andrei Alexandrescu wrote:
On 3/20/12 12:50 AM, Kapps wrote:
Perhaps we should add a field of type Variant[string].
No, not Variant[string] again.
Why? I thought it was agreed
Le 20/03/2012 17:16, Andrei Alexandrescu a écrit :
Maybe there's a better approach than flectioned. Consider the language
is frozen solid. How would you solve problems with it?
Easy, I already did that many times. I'd preprocess the source code with
some homebrew tool before compiling.
Le 20/03/2012 17:13, Andrei Alexandrescu a écrit :
On 3/20/12 10:52 AM, Jacob Carlborg wrote:
On 2012-03-20 16:17, Andrei Alexandrescu wrote:
On 3/20/12 12:50 AM, Kapps wrote:
Perhaps we should add a field of type Variant[string].
No, not Variant[string] again.
Why? I thought it was agre
Le 20/03/2012 20:17, Andrei Alexandrescu a écrit :
On 3/20/12 2:04 PM, Piotr Szturmaj wrote:
Andrei Alexandrescu wrote:
On 3/20/12 10:52 AM, Jacob Carlborg wrote:
On 2012-03-20 16:17, Andrei Alexandrescu wrote:
On 3/20/12 12:50 AM, Kapps wrote:
Perhaps we should add a field of type Variant
Le 20/03/2012 16:17, Andrei Alexandrescu a écrit :
On 3/20/12 12:50 AM, Kapps wrote:
On Monday, 19 March 2012 at 21:00:32 UTC, Andrei Alexandrescu wrote:
On 3/19/12 3:55 PM, F i L wrote:
I think this could get tricky for the compiler to confidently use given
that the mixed in enums can collide
On 3/20/12 2:04 PM, Piotr Szturmaj wrote:
Andrei Alexandrescu wrote:
On 3/20/12 10:52 AM, Jacob Carlborg wrote:
On 2012-03-20 16:17, Andrei Alexandrescu wrote:
On 3/20/12 12:50 AM, Kapps wrote:
Perhaps we should add a field of type Variant[string].
No, not Variant[string] again.
Why? I
Andrei Alexandrescu wrote:
On 3/20/12 10:52 AM, Jacob Carlborg wrote:
On 2012-03-20 16:17, Andrei Alexandrescu wrote:
On 3/20/12 12:50 AM, Kapps wrote:
Perhaps we should add a field of type Variant[string].
No, not Variant[string] again.
Why? I thought it was agreed that that's a good id
On 03/20/2012 05:31 PM, Adam D. Ruppe wrote:
Even /ignoring/ them takes a lot code, and that's
what, to me, pushes it over into compiler territory.
vote++
On Tuesday, 20 March 2012 at 15:17:04 UTC, Andrei Alexandrescu
wrote:
Also, as I mentioned, the availability of the easy escape hatch
of adding a language feature thwarts creativity.
I agree entirely. Usually, when I see threads like this,
my response is "challenge accepted".
But, on this prob
On 3/20/12 11:09 AM, Steven Schveighoffer wrote:
On Tue, 20 Mar 2012 11:17:02 -0400, Andrei Alexandrescu
wrote:
I'm afraid I disagree. A targeted language feature definitely makes a
library approach inferior, by definition. But adding features is
cheating, like printing money is for a governmen
On 3/20/12 11:09 AM, Steven Schveighoffer wrote:
On Tue, 20 Mar 2012 11:17:02 -0400, Andrei Alexandrescu
wrote:
Perhaps we should add a field of type Variant[string].
1. Variant is not (and shouldn't be IMO) part of druntime.
2. This is *static* data that should be available at compile time.
On 3/20/12 10:52 AM, Jacob Carlborg wrote:
On 2012-03-20 16:17, Andrei Alexandrescu wrote:
On 3/20/12 12:50 AM, Kapps wrote:
Perhaps we should add a field of type Variant[string].
No, not Variant[string] again.
Why? I thought it was agreed that that's a good idea for exceptions.
I'm not
On Tue, 20 Mar 2012 11:17:02 -0400, Andrei Alexandrescu
wrote:
Perhaps we should add a field of type Variant[string].
1. Variant is not (and shouldn't be IMO) part of druntime.
2. This is *static* data that should be available at compile time. D's
runtime wasting cycles filling in static
Andrei Alexandrescu wrote:
like printing money is for a government: very tempting, with
apparently good short-term benefits, but with devastating
cumulative effects.
RON PAUL 2012!!!
sorry, I couldn't help myself.
Also, as I mentioned, the availability of the easy escape hatch
of adding a
On 2012-03-20 16:17, Andrei Alexandrescu wrote:
On 3/20/12 12:50 AM, Kapps wrote:
Perhaps we should add a field of type Variant[string].
No, not Variant[string] again.
This is an already ridiculously hackish approach, and
it *does not* work for anything besides trivial applications. It is
On 3/20/12 1:22 AM, dennis luehring wrote:
and how to add attribute parameters like DoSerialize(type=packed) for
example - very very common in C# attributes and java annotations
http://en.wikipedia.org/wiki/Java_annotation
One more argument to the template?
Andrei
On 3/20/12 12:50 AM, Kapps wrote:
On Monday, 19 March 2012 at 21:00:32 UTC, Andrei Alexandrescu wrote:
On 3/19/12 3:55 PM, F i L wrote:
I think this could get tricky for the compiler to confidently use given
that the mixed in enums can collide with existing members (although not
likely). Also,
On 2012-03-20 10:49, F i L wrote:
That's pretty slick. D would need delegate inlining + @forceInline
before foreach could be expressed this way though.
Yes, but currently, as far as I know, the delegate passed to opApply is
not inlined.
--
/Jacob Carlborg
Jacob Carlborg wrote:
If D supported passing delegates to a function after the
function call several language features could have been
implemented in the library instead.
void synchronized (void delegate () dg)
{
try
{
lock();
dg();
}
finally
unlock();
}
On 2012-03-19 22:00, Andrei Alexandrescu wrote:
I salute creative uses of the language over defining new features.
Andrei
The actual point of user defined attributes it to be able to create
domain specific attributes so we don't have to add new features to the
language. This is also to have
On 2012-03-19 22:51, Andrej Mitrovic wrote:
On 3/19/12, Jacob Carlborg wrote:
Yeah, but that will complicate the retrieval of the information.
What is so complicated about extracting fields? Just iterate via .tupleof:
It wasn't actually that much more complicated. But now there is one
extr
and how to add attribute parameters like DoSerialize(type=packed) for
example - very very common in C# attributes and java annotations
http://en.wikipedia.org/wiki/Java_annotation
Am 19.03.2012 22:00, schrieb Andrei Alexandrescu:
On 3/19/12 3:44 PM, Andrej Mitrovic wrote:
On 3/19/12, Jacob C
On Monday, 19 March 2012 at 21:00:32 UTC, Andrei Alexandrescu
wrote:
On 3/19/12 3:55 PM, F i L wrote:
I think this could get tricky for the compiler to confidently
use given
that the mixed in enums can collide with existing members
(although not
likely). Also, if objects are not identified as b
On 3/19/12, Jacob Carlborg wrote:
> Yeah, but that will complicate the retrieval of the information.
What is so complicated about extracting fields? Just iterate via .tupleof:
module test;
import std.stdio;
import std.conv;
struct Foo
{
int x;
string name;
mixin NonSerialized!name;
On 2012-03-19 22:00, Andrei Alexandrescu wrote:
I salute creative uses of the language over defining new features.
Andrei
Sure, just as well as you can do object oriented programming in C, but
it is a mess. So is this.
--
/Jacob Carlborg
On 2012-03-19 21:44, Andrej Mitrovic wrote:
When I implemented NonSerialized for Vladimir's json library he made a
suggestion to simply create enums of each field that is not to be
serialized and encode it as "fieldname_nonSerialized". That would
enable using a NonSerialized mixin multiple times
Andrej Mitrovic wrote:
Also I've no idea what "objects being unique marked" means.
I meant that Attribute metadata is distinct data in the compilers
eyes, ie, no name magic, just attribute lookup.
On Mon, Mar 19, 2012 at 04:00:00PM -0500, Andrei Alexandrescu wrote:
> On 3/19/12 3:44 PM, Andrej Mitrovic wrote:
[...]
> >So all you'd have to do is use compile-time introspection and a
> >little bit of string processing to figure out if a field should be
> >serialized or not.
>
> I salute creati
On Monday, 19 March 2012 at 21:00:32 UTC, Andrei Alexandrescu
wrote:
On 3/19/12 3:55 PM, F i L wrote:
I think this could get tricky for the compiler to confidently
use given
that the mixed in enums can collide with existing members
(although not
likely). Also, if objects are not identified as b
On 3/19/12 3:55 PM, F i L wrote:
I think this could get tricky for the compiler to confidently use given
that the mixed in enums can collide with existing members (although not
likely). Also, if objects are not identified as being unique marked (in
the compilers eyes), what specific attribute pos
On 3/19/12 3:44 PM, Andrej Mitrovic wrote:
On 3/19/12, Jacob Carlborg wrote:
* Can be repeated on several fields (with the mixin you can only mixin
"NonSerialized" once)
When I implemented NonSerialized for Vladimir's json library he made a
suggestion to simply create enums of each field that
On 3/19/12, F i L wrote:
> Also, if objects are not identified as
> being unique marked (in the compilers eyes), what specific
> attribute post-fixes will it be searching for on enums members?
I'm really not talking about general-purpose attributes, I was
commenting on a specific serialization ex
On Monday, 19 March 2012 at 20:44:43 UTC, Andrej Mitrovic wrote:
On 3/19/12, Jacob Carlborg wrote:
* Can be repeated on several fields (with the mixin you can
only mixin
"NonSerialized" once)
When I implemented NonSerialized for Vladimir's json library he
made a
suggestion to simply create
On 3/19/12, Jacob Carlborg wrote:
> * Can be repeated on several fields (with the mixin you can only mixin
> "NonSerialized" once)
When I implemented NonSerialized for Vladimir's json library he made a
suggestion to simply create enums of each field that is not to be
serialized and encode it as "
On 2012-03-19 13:31, Steven Schveighoffer wrote:
On Sun, 18 Mar 2012 04:03:29 -0400, Walter Bright
I mean there is modifiable-at-runtime, instance-specific data.
I don't think we should go this far with attributes. If you want to
store instance-specific data, we already have a place for that.
On Monday, 19 March 2012 at 00:41:44 UTC, Walter Bright wrote:
Maybe this is why I don't much care for attributes - it's all
just a fog to me what is happening.
Maybe this will help:
http://research.microsoft.com/en-us/um/people/cszypers/events/WCOP2006/rouvoy-wcop-06.pdf
Attribute-Oriented
1 - 100 of 168 matches
Mail list logo
