On Thu, Nov 19, 2009 at 5:17 PM, Leandro Lucarella <llu...@gmail.com> wrote: > Bill Baxter, el 19 de noviembre a las 14:16 me escribiste: >> > What I found hackish about it is that the code is a string manipulation >> > mess. You can already do a string manipulation mess to programatically >> > implement all the operator overloading. >> >> This is true, but if you leave it entirely up to the programmer and >> string mixins, the mess is much more messy. >> You're going to end up with code like this: >> >> mixin(genBinaryOp("+", q{MyType}, q{MyType rhs}, q{ >> return this.impl + rhs.impl; >> })); >> >> >> instead of this: >> MyType opBinary(string op : "+")(MyType rhs) { >> return this.impl + rhs.impl; >> } >> >> I would have a hard time defending the former as the recommended D style. >> But the latter is not so bad. It looks like a regular template >> declaration, and code is code, not a string. > > But in this case you gained nothing comparing to opAdd(), where opBinary() > is useful is where you use string mixins to avoid implementing the > operators one by one. > > I know the opBinary() approach is less ugly than writing the code youself, > but a library solution could be provided in the meantime (in the > unexistent std.mixin module; which BTW, can't be named that way because > "mixin" is a keyword ;).
My point was that the best you're going to be able to do with a library solution (even for multiple operators) would be to provide a "genBinaryOp" function, making your code look something like this: mixin(genBinaryOps("+ - * /", q{MyType}, q{MyType rhs}, q{ return this.impl $op rhs.impl; })); Or I guess with more effort you could probably have something like this: mixin(genBinaryOps("+ - * /", q{ MyType $opName(MyType rhs) { return this.impl $op rhs.impl; } })); But I still find the plain template idea cleaner for the user than a string generation function that does heck knows what. --bb