opXAssign overloading
dsimcha
dsimcha at yahoo.com
Mon Oct 12 21:31:32 PDT 2009
It seems that D's operator overloading is a bit silly in some cases w.r.t.
opAddAssign, opSubAssign, etc. Consider the following example:
struct Foo {
Foo opAdd(Foo rhs) {
return this;
}
}
void main() {
Foo foo;
Foo bar;
foo = foo + bar; // Works.
foo += bar; // Doesn't work.
}
I'm thinking (not sure if this was proposed here before a while back and I
just forgot where I heard it from) that the default behavior of
someObject.opXAssign(otherStuff); should be to expand into someObject =
someObject.opX(otherStuff); if opXAssign is not overloaded. Besides the
programmer being too lazy to explicitly overload opXAssign, I just found
another use case.
Suppose you have a bunch of classes and you're overloading operators such that
each call builds another layer of decorators. For example:
class SomeClass {
SomeClass opAdd(SomeClass rhs) {
// SomeDecorator is a subclass of SomeClass.
return new SomeDecorator(this, rhs);
}
}
In this case, you *can't* overload SomeClass.opAddAssign in any reasonable way
because you can't assign SomeDecorator to this, but translating
someInstance.opAddAssign(someOtherInstance) into someInstance =
someInstance.opAdd(someOtherInstance) makes perfect sense.
More information about the Digitalmars-d
mailing list