On Tue, 11 Mar 2014 04:39:39 -0600, Ian Kelly wrote:
> On Mon, Mar 10, 2014 at 11:03 PM, Gregory Ewing
> <greg.ew...@canterbury.ac.nz> wrote:
>> As far as observable effects are concerned, it's quite clear: mutable
>> objects can *always* be updated in-place, and immutable objects can
>> *never* be.
>
> Hm. Consider the circle-ellipse problem.
Oh, not that old chestnut! The circle-ellipse problem demonstrates one
limitation of OOP (specifically "subtype polymorphism"), as well as a
general difficulty with hierarchical taxonomies. Mammals have hair --
what do you make of hairless[1] dolphins? Circle/Ellipse is not a good
place to start from in order to critic augmented assignment in Python.
You're starting from a place where inheritance itself is problematic, so
naturally you're going to find problems.
> Briefly, a circle is-an ellipse, so in an inheritance hierarchy it is
> natural to make Circle a subclass of Ellipse.
Natural and wrong. It's only natural if you don't think through the
consequences. As you go on to say:
> Now suppose the Ellipse has a stretch method that
> mutates the ellipse by changing the length of one of its axes while
> preserving the other. To avoid violating LSP, the Circle class must
> support all the methods of its ancestor. However it cannot, because the
> stretch method would invalidate the invariant of the Circle class that
> both of its axes must always be equal.
Right. So *Circles cannot be Ellipses*, not without violating the Liskov
Substitution Principle. If I think that they are, I haven't thought it
through. Nor can Ellipses be Circles. That's the problem of the Circle/
Ellipse relationship.
(Aside: the LSP is not a Law Of Physics that cannot be touched. There are
other OOP models that don't require LSP.)
Even in the case of immutable shapes, one might not wish to inherit
Circle from Ellipsis. Ellipses have five degrees of freedom:
2 x position
size (scale)
orientation
shape
while circles only have three:
2 x position
size
Orientation and shape are meaningless for circles! So they should not
inherit from a class where they are meaningful: given the LSP, a subclass
cannot be more restrictive than a superclass.
> There are a number of possible solutions. One possibility would be to
> copy the Circle as an Ellipse and return the new object instead of
> mutating it. Then you have the situation where, given a mutable object
> x that satisfies isinstance(x, Ellipse), the stretch method *may* be
> able to update the object in-place, or it *may* not.
That is a really lousy design. Of course we are free to create classes
with ugly, inconsistent, stupid or unworkable APIs if we like. Python
won't stop us:
class MyList(list):
def append(self, obj):
if len(self) % 17 == 3:
return self + [obj]
super(MyList, self).append(obj)
> I can't think of a reasonable example that would replace the stretch
> method here with an augmented assignment, but then it is rather late.
>
>> It might be the obvious way for that particular operation on that
>> particular type.
Um, yes? Nobody suggests that a method of type X has to be the most
obvious way for *any operation* on *any type*. What's your point?
> But what about all the others? What's the obvious way
>> to spell in-place set intersection, for example?
I would expect it to be &=, let's find out if I'm right:
py> a = set("abcde")
py> b = a # save a reference to it
py> c = set("cdefg")
py> a &= c
py> a, b
({'c', 'd', 'e'}, {'c', 'd', 'e'})
py> a is b
True
>> (Quickly -- no peeking at the docs!)
The only reason I'd need to look at the docs is because I always forget
whether & is intersection and | is union, or the other way around. But
having remembered which is which, going from & to &= was easy.
> You mean set.intersection_update? The in-place set methods are not hard
> to remember, because they all end in _update.
And hard to spell.
[1] Technically they aren't *entirely* hairless. They may have a few
hairs around the blowhole, and baby dolphins are born with whiskers which
they soon lose. But from a functional perspective, they are hairless.
--
Steven D'Aprano
--
https://mail.python.org/mailman/listinfo/python-list
