dynamic classes and duck typing

[Bill Baxter]

On Tue, Dec 1, 2009 at 3:01 PM, Steven Schveighoffer
<schveiguy at yahoo.com> wrote:
>> How about this: given only a catch-all opDispatch which implements
>> dynamic dispatch, the compiler cannot statically determine if
>> operators are really implemented or not.
>
> Why does it have to?
> proposed implementation:
>
> compiler sees 'a + b'
> compiler rewrites 'a.opBinary!"+"(b)'
> does it compile?  If yes, then a implements the operator.
>
> With opDispatch:
>
> compiler sees 'a + b'
> compiler rewrites 'a.opDispatch!"+"(b)'
> does it compile?  If yes, then a implements the operator.
>
> I don't see the problem.
>
>> Since the list of operators
>> is always finite, it makes sense to have them in a separate
>> "namespace" of sorts.   That way if you implement a catch-all
>> opBinary, you're only saying that you implement all /operators/ not
>> all possible methods.  And vice versa, you can specify that you only
>> implement some operators, but still have dynamic dispatch that
>> forwards all named methods.
>
> opDispatch(string s, T)(T arg) if(isOperator(s))
>
> opDispatch(string s, T...)(T arg) if(isSymbol(s))

Good counterpoints to my argument.  So I give up on that line.

Here's another, how do you implement the opBinary_r operators with opDispatch?

--bb