"Jacob Carlborg" <[email protected]> wrote in message news:[email protected]... > 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"<[email protected]> wrote in message >>>> news:[email protected]... >>>> >>>>> 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.
