On Monday, 6 May 2013 at 21:58:08 UTC, Steven Schveighoffer wrote:
On Mon, 06 May 2013 17:13:00 -0400, Idan Arye
<generic...@gmail.com> wrote:
On Monday, 6 May 2013 at 19:47:33 UTC, Diggory wrote:
It's a nice idea but personally I don't like the syntax much,
for example it's completely non-obvious what "true" does when
passed to the singleton mixin, or that the parameters to the
property mixin are "type, name, condition, initial value".
I suppose you could do something like this:
mixin property!`int x = 1`;
The other problem is that I don't think it's beneficial to
invite the use of mixins for such simple substitutions. I'd
rather see the majority of code be standard D syntax, and the
use of mixins be the exception rather than the rule. It's
similar to how excessive use of macros in C++ is generally
considered bad practice.
If D supported Java's annotation metaprogramming I could have
implemented a syntax like:
@Property(`a < 50`) int a = 1;
since it doesn't, I have to use mixin templates...
D supports @Property syntax (though I would suggest a different
identifier) via User-defined-attributes. However, you will
still need the mixin, I don't think it can add code.
This brings up a good idiom though. Since mixin is the only
thing that can inject code, but its usage is ugly, @uda's can
be useful for specifying nice parameters to the mixin, and you
could have one mixin per class instead of per property. I
think Manu uses this to great effect (was in his first talk).
-Steve
I don't like this idea of marking the class with a `mixin`
statement, and having all the parameters fed to it somewhere
else. It doesn't feel clean to me...
And feeling aside, there was one thing I neglected - in Java the
convention is to use `getX` and `setX` as `x`'s accessors, but in
D the convention is to use `@property` accessors. Now, if we
wrote:
class Foo
{
private @Property int x;
mixin makeProperties;
}
then `makeProperties` would have made:
@property int x(){...}
@property int x(int value){...}
And we wouldn't be able to use them because they are overshadowed
by the original x! That means we would have to rename `x` to
`m_x` and either supply the desired property name as a UDA
attribute or analyze the variable's name to remove the prefix
notation.
Not as elegant as we wanted.
However, your idea of having a single mixin handle all the
class\struct's properties gave me another idea - to use a single
mixin, but instead of having it analyze the owner class to find
the fields we want to make properties, we simply give them to it
with a token string:
class Foo
{
mixin properties!q{
@asserting(`a < 50`) int x = 1;
@verifying(`a !is null`) string y = "hello";
@privateSetter double z = 44.4;
};
}
This can be easily implemented by making a private `struct` and
`mixin`ing all those declarations as it's arguments, which gives
me a data structure schema to query with `std.traits`, and also
allows me to define the UDA's so that they can only be used
inside the `mixin properties` "block". Also, it encourages
programmers to put all their member fields in the same section of
the class\struct.
One problem I see here, BTW, is DDoc - I have no idea how to
document properties created like this...
