New syntax for string mixins

[Nick Sabalausky]

"Jacob Carlborg" <doob at me.com> wrote in message 
news:iee561$v5s$1 at digitalmars.com...
> On 2010-12-16 23:05, Jonathan M Davis wrote:
>> On Thursday, December 16, 2010 11:28:03 Jacob Carlborg wrote:
>>> On 2010-12-15 23:00, Nick Sabalausky wrote:
>>>> "Jonathan M Davis"<jmdavisProg at gmx.com>   wrote in message
>>>> news:mailman.1035.1292441722.21107.digitalmars-d at puremagic.com...
>>>>
>>>>> On Wednesday, December 15, 2010 11:27:47 Jacob Carlborg wrote:
>>>>>> That was my idea as well, that
>>>>>>
>>>>>> @get_set("int", "bar");
>>>>>>
>>>>>> could be translated into
>>>>>>
>>>>>> mixin(get_set("int", "bar")); just like
>>>>>>
>>>>>> just like scope statements are translated into try/catch/finally.
>>>>>
>>>>> Honestly, I don't see much gain in using @ rather than mixin(). It's a
>>>>> little
>>>>> less typing, but that's it.
>>>>
>>>> It does seem like a small difference, just replacing "mixin" with "@" 
>>>> and
>>>> removing one layer of parens. But I think that extra layer of parens,
>>>> minor as it seems, makes a big difference in the readability (and
>>>> "typeability") of mixin invocations. Those extra parens do get to be a
>>>> real bother, major visual noise at least to my eyes.
>>>
>>> ^^ I completely agree.
>>>
>>>>> And it precludes stuff like mixin("lhs " ~ op ~ "
>>>>> rhs") like happens all the time in overloaded operator functions.
>>>>
>>>> I don't see why these shouldn't work:
>>>>
>>>> @"int foo;";
>>>> return @("lhs " ~ op ~ " rhs");
>>>>
>>>> At least with just the "@" part of the proposal. Maybe the delegate 
>>>> thing
>>>> might make it tricker, I dunno.
>>>
>>> My idea was actually to get rid of the strings where the code to be
>>> mixed in is defined and to have a better syntax where it's used.
>>>
>>> The delegates are just a way of passing a block of code around. If you
>>> just use it in place then maybe one could do like this:
>>>
>>> @(int foo;);
>>> return @(lhs@(op)rhs);
>>
>> I would have thought that template mixins would be the thing to use when 
>> you
>> didn't want to deal with strings. string mixins are extremely powerful 
>> and
>> flexible, and I'd really hate to lose them. And IIRC, Kenji Hara was 
>> working on a
>> module to really help make dealing with complicated string mixins easier 
>> and
>> less painful. Anything that you propose is going to have to have major 
>> benefits
>> over the current string mixin situation for it to stand any chance of 
>> being
>> accepted.
>>
>> - Jonathan M Davis
>
> Template mixins and string mixins are used for different things. There's a 
> lot of things that string mixins can do that template mixins can't. I have 
> no intention what so ever to suggest something that isn't as powerful as 
> string mixins, just a new syntax. If it turns out that a having a powerful 
> syntax without strings isn't possibles than I'll guess we have to live 
> with the strings.
>
> Don't know if you read my first post put there I wrote that it wasn't a 
> real suggestion (at least not yet) I just wanted the community's thoughts 
> on the idea and see if we could turn it into something useful that could 
> become a real suggestion, if people where interested.
>
> The ideas I wrote in my extended suggestion, "Taking it one step further", 
> I think that those can have benefits over string mixins. Basically 
> allowing you to pass the whole body of a class declaration to a function, 
> as a delegate, with a syntax looking like Java annotations.
>

It would seem to make sense to treat "chucks of code" the same way 
regardless of whether you're passing them around, mixing them in or 
instantiating them as a template.