New syntax for string mixins

Nick Sabalausky a at a.a
Thu Dec 16 12:35:01 PST 2010


"Jacob Carlborg" <doob at me.com> wrote in message 
news:iedpbg$3i0$1 at digitalmars.com...
> On 2010-12-15 23:00, Nick Sabalausky wrote:
>>
>> 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);
>

Yea, my point was just that the "@..." stuff could work either way, with the 
string-based system or with your delegate-based one.

I don't mean to come across like I'm ignoring or against the idea of the 
whole delegate aspect, and I understand that the main point of the OP is to 
replace the strings with delegates, but with the q{...} syntax and 
string-templating, I'm still struggling to see a big enough benefit compared 
to the status quo. I see that using delegates instead of strings could 
probably be made to work, but my questions are "For what benefit(s)?" and 
"Would those benefits be sufficient to warrant the change?" I'm not 
necessarily saying the answer is "no", but I'm unconvinced so far.

And here's another thing: Suppose we got a Ruby/PHP-like syntax for 
embedding code substitutions directly into a string (which would have other 
useful applications besides mixins):

auto name = "Joe";
auto msg = "hello #{name}, whaddup?";
mixin( q{ int #{name} = 7; } );
Joe++;

Would that eliminate much (or all) of the benefit of the delegate approach?




More information about the Digitalmars-d mailing list