On 11/16/06, Talin <[EMAIL PROTECTED]> wrote: > As far as multiple dispatch goes: I would agree here as well, especially > when we talk about binary operations. For example, suppose we have two > objects, a and b, which are of types A and B respectively. And suppose > each of those types overloads both __add__ and __radd__: > > class A: > def __add__( self, other ): > ... > def __radd__( self, other ): > ... > > class B: > def __add__( self, other ): > ... > def __radd__( self, other ): > ... > > a = A() > b = B() > > print a + b # __add__ wins over __radd__, but should it? > print b + a > > My conclusion: Single dispatch systems are a poor way to specify > operator overloading. Compare this to the corresponding generic dispatch > case: > > @generic( A, A ) > def __add__( p0, p1 ): > ... > > @generic( A, B ) > def __add__( p0, p1 ): > ... > > @generic( B, B ) > def __add__( p0, p1 ): > ... > > @generic( B, A ) > def __add__( p0, p1 ): > ... > > With multiple dispatch, its easy to spell out what will happen in each > possible permutation of arguments - and if you get an ambiguity, the > dispatcher will let you know about it, instead of simply choosing an > implementation arbitrarily.
Interesting idea, certainly not mainstream for the moment though. Short question: how do multiple dispatch systems deal with the combinatorial explosion ? I guess there should be a way to avoid having to spell out all combinations every time, or it will soon be unpractical. George _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
