Fredrik Lundh wrote:
> I'm convinced that it's better for people to get over that silly notion
> that writing x.foo() is somehow always "better" than writing foo(x), in
> a language that actually supports both forms.
>
> (if I'd have to chose between foo(x) and x.foo(), I'd rather get foo(x)
> with multiple dispatch than today's x.foo() single dispatch, but that's
> probably too radical for Python 3000 ;-)
I'm in agreement with this. Since OOP was first popularized, there have
been various schools of thought which taught that object oriented
programming was "good style", and any reversion to a more functional or
procedural syntax was "bad style". I really wish that people would get
over this.
At the moment, there are, by my count, at least four and perhaps as many
as a dozen "styles" or program organization, all of which have more or
less validity in any given situation.
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.
-- Talin
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
