On Wed, Nov 18, 2009 at 10:55 PM, Rainer Deyke <rain...@eldwood.com> wrote: > Andrei Alexandrescu wrote: >> I am thinking that representing operators by their exact token >> representation is a principled approach because it allows for >> unambiguous mapping, testing with if and static if, and also allows >> saving source code by using only one string mixin. It would take more >> than just a statement that it's hackish to convince me it's hackish. I >> currently don't see the hackishness of the approach, and I consider it a >> vast improvement over the current state of affairs. > > Isn't opBinary just a reduced-functionality version of opUnknownMethod > (or whatever that is/was going to be called)? > > T opBinary(string op)(T rhs) { > static if (op == "+") return data + rhs.data; > else static if (op == "-") return data - rhs.data; > ... > else static assert(0, "Operator "~op~" not implemented"); > } > > T opUnknownMethod(string op)(T rhs) { > static if (op == "opAdd") return data + rhs.data; > else static if (op == "opSub") return data - rhs.data; > ... > else static assert(0, "Method "~op~" not implemented"); > } > > I'd much rather have opUnknownMethod than opBinary. If if I have > opUnknownMethod, then opBinary becomes redundant.
opBinary doesn't really become redundant because you still need the _r variants. You could come up with some convention for the string that represents the _r flavor of opUnknownMethod!("-") but why not just make'em different methods? I don't think there's enough in common between a typical operator and a generic unknownMethod to make fusing them worth it. --bb