dynamic classes and duck typing

[Steven Schveighoffer]

On Tue, 01 Dec 2009 16:01:41 -0500, Bill Baxter <wbaxter at gmail.com> wrote:

> On Tue, Dec 1, 2009 at 12:38 PM, Steven Schveighoffer
> <schveiguy at yahoo.com> wrote:
>> On Tue, 01 Dec 2009 15:06:27 -0500, Pelle Månsson  
>> <pelle.mansson at 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