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

[Alex Martelli]

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

Not in programming (the number of different programs is _countably_
infinite, since we write them with a finite alphabet), only in maths.

> 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

Not conceptually, in a language where the definition of classes also
changes continually.  And if you do want change, why shouldn't it?

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

There's no practical usefulness at all in having all objects recompute
their set memberships at each change in the objects and/or the set
definitions, of course -- and there's no theoretical interest in it at all
for me, either, when checking membership on the fly "just in time" is
so obviously workable and conceptually clean.  The "tracking" of set
memberships is useless conceptual overhead, just as it would be
absurd pragmatical overhead.

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

"typing" has no real match to reality.  Set membership does, but
the "tracking" you seem to desire doesn't.

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

But what would that "good system" accomplish that is of any interest
whatsoever?  The very idea of letting object changes but NOT allowing
the same dynamicity for types, on which so many current languages are
based, is half-cocked anyway.

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

In a way, yes, although Dylan is smoother in keeping parallelism
between the various objects involved, while Haskell has different
pluses.


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

Quite often, if we wrote complete axioms.  We don't, because even
our "assertion languages" (such as Eiffel's require/ensure clauses) are
oriented to execution, so the universal quantifiers that are such a must
for good axiomatization (in the above notation there are several implied
"for any":-) can't even be conceived within the confines of those
languages, AND because axiomatization under change is so much more
of a bother (you keep having to introduce alien ideas about "before"
and "after", seemingly intuitive to humans but extra baggage for
formal manipulation).

> "pragmatism beats purity" mean we shouldn't worry overly much about such
> things?  "If it gets the job done .." and all that. <g>

The very substantial investment in axiomatization of imperative
languages over the last 40-ish years has certainly yielded small
pragmatic benefits so far (particularly when compared to the
higher cost/benefit ratio for the effort to make FP languages
practical).  "Small" is not 0, of course.


Alex