On Tue, 01 Dec 2009 16:01:41 -0500, Bill Baxter <wbax...@gmail.com> wrote:
On Tue, Dec 1, 2009 at 12:38 PM, Steven Schveighoffer
<schvei...@yahoo.com> wrote:
On Tue, 01 Dec 2009 15:06:27 -0500, Pelle Månsson
<pelle.mans...@gmail.com>
wrote:
Steven Schveighoffer wrote:
Isn't opBinary almost identical to opDispatch? The only difference I
see is that opBinary works with operators as the 'symbol' and
dispatch works
with valid symbols. Is it important to distinguish between operators
and
custom dispatch?
-Steve
opBinary is a binary operator, opDispatch can be anything. I think they
should be kept separate.
You could say the same thing about dynamic properties. How come we
don't
split those out as opProperty?
That's because of what Andrei pointed out: &a.b .
The compiler can't tell if you want a delegate to the method b, or the
address of a property b.
Huh?
opDispatch can do opBinary, it's a subset. It makes no sense to define
opDispatch(string s)() if(s == "+") I agree, but I don't see any reason
why
opBinary(string s)() would fail to compile...
I don't get your point. It's the compiler that decides to call
opBinary and it's only gonna decide to do so for binary operators.
Even if you pretend opBinary can accept any string.
My point is, the set of strings passed by the compiler to opBinary is
completely disjoint from the set of strings passed by the compiler to
opDispatch. So the only reason to keep them separate is because you want
to force people to split their code between operators and
methods/properties.
There is no technical reason we need to keep them separate or to combine
them that I can see.
-Steve
