I want to add a Phobos module with template mixins for common idioms.

[Idan Arye]

On Monday, 6 May 2013 at 21:58:08 UTC, Steven Schveighoffer wrote:
> On Mon, 06 May 2013 17:13:00 -0400, Idan Arye 
> <GenericNPC at 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...