Travis Boucher wrote:
Rainer Deyke 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.
Passing op as the symbol allows for mixin("this.data"~op~"that.data;");
Also it does not require remembering the correspondence between symbols
and their names.
What I was hoping for was a catch-all for unknown non-operation methods,
which could allow for dispatching to functions that are not even known
at runtime (ie. trigger a lookup in a shared object, or pass along to a
scripting language engine).
I agree. This is something very interesting.
Andrei
