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

[Gary Stephenson]

"Alex Martelli" <aleax at aleax.it> wrote in message
news:k2dq8.50144$S52.1717644 at news2.tin.it...

> Gary Stephenson wrote:
>         ...
> > 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.

I'm not sure we are actually talking about uncountably infinite sets here -
are we?.  Isn't it rather the finite and (probably) small set of heir
classes that need to be kept track of?  (I do agree that even this is
probably way too much book-keeping overhead to make it practicable in the
real world.)  And modelling "Change" well is surely something that we all
need to continually improve upon.

> 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.

I have yet to really come to grips with Haskell - but look forward to doing
so.  However, I think what we are looking for here is not so much a closer
match to maths, but a closer match to reality - which has always been one of
the O-O's great marketing points - that it (supposedly) models reality more
closely.  Besides, just because nobody has yet come up with a really good
imperative system for subtyping doesn't necessarily mean that it's all
"tilting at windmills" (though it may very well prove to be so!).

> > 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.

Err, as I said, I'm not terribly Haskell enlightened (yet).  Does this
perhaps relate in some way to Dylan's approach of eschewing methods in
favour of generic functions (multi-methods)?

> 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.

Probably so.  But one man's "peculiar waste of time" might be another man's
life obsession.   Personally I am rather reluctant to label another person's
obsessions a "waste of time" - you just never know when they might come up
with something insanely great!  For example, some _very_ smart folk are
striving to
achieve a synergistic synthesis of the functional and imperative paradigms
[1]

> 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?

Yes. Extremely lucid and succinct!  I wonder how often such axiomatic
analysis
would identify pathology in our inheritance relationships.  Or does
"pragmatism beats purity" mean we shouldn't worry overly much about such
things?  "If it gets the job done .." and all that. <g>

Many thanks for your thoughts - they are, as always, most illuminating.

respectfully,

gary

[1] - http://www.uwm.edu/~whopkins/seqcd/jolt.txt