Subclass sadness (was Re: [Python-Dev] PEP 285: Adding a bool type)

[Alex Martelli]

Gary Stephenson wrote:
        ...
> an air of artificiality about them, there are numerous instances in the
> real world where things _do_ mutate over time, and belong to varying sets
> of
> categories as a consequence of such mutation.   

Sure.  It's easy to see that any change removes membership of an
uncountably infinite number of sets and adds membership ditto.  We
can't model that perfectly (infinities are hard to model, uncountable
ones in particular) but we can come decently close (for most sets of
interest) by modeling each set by its characteristic predicate.

> Given that our objects
> _are_ allowed to mutate their state, wouldn't it be preferable for them to
> do so in more intelligent ways?  

No.  "Change" is such a troublesome notion already, that to have it
train behind itself a "keeping track of uncountably infinite sets" is
quite a conceptual mountain.

> Whether such a notion is actually
> implementable in the real world is an entirely different question  of
> course ;-)

Objects that do not change are perfectly well implementable and quite
usable.  Anybody looking for a closer match to maths should IMHO turn
right to lazy FP (Haskell...) rather than tilt agains the windmill of 
'proper' modeling of change.

> Simple immutability is also insufficient to enable the subclass == subtype
> identity [1], which seems to me to be one of the fundamental issues
> underlying all this.

Yes.  If you realize that 'behavior' is never intrinsic to a set of values, 
and systematically _superimpose_ behavior on value sets (Haskell's
typeclasses being of course the right way to do that:-), then you complete
the conceptual trip to systematic purity.  Then you can decide whether
the pragmatics of Python are preferable to the purity of Haskell, but if
you do then it's a peculiar waste of time to keep yearning for purity after
choosing the compromise route of pragmatism.

The set/bag example under immutability depends on functions such as
put and remove returning new sets/bags -- a conceptual approach that
simplifies things a lot, even though implementation-wise it may be too
heavy.  But the insights you gain from there are still valuable and to some
extent applicable to impure worlds with mutating objects.  Among bag's
axioms (w has/put/remove) should be something like the material implication:
    (has item bag) => (has item (remove item (put item bag)))
and among set's axioms w has/put/remove should be:
    () => (not (has item (remove item set)))
so the impossibility of any one entity X satisfying both sets of axioms
is trivial to prove, no?


Alex