Smalltalk and Python

[Alex Martelli]

"Tim May" <tcmay at got.net> wrote in message
news:tcmay-04E80C.16181313122000 at news.got.net...
    [snip]
> Being interested in ontology (things, objects, hierarchies, structures)
> even more so than in advocating any one language over another, I would
> be fascinated to see some good examples of MI in actual use.

I can't find a source any more, but one of the most interesting
arguments I've heard for "only inherit from abstract classes"
(which is a precious, highly-practical rule of thumb for C++
and other languages, championed on practical grounds by Scott
Meyers and other C++ gurus) is actually ontology-based, and
aimed at the object-oriented analysis stage.

What classes are 'abstract' (not actually instantiated as
themselves, but only in terms of their subclasses) or 'concrete'
(directly instantiable without subclassing) is part of what your
O-O analysis is determining, and will depend on what exactly
you're trying to do.  The root of the 'only abstract classes
ever get subclassed' idea is that there is an inconsistency
of levels-of-detail in your analysis if it allows subclassing
of instantiable classes.  If your application-needs (or more
generally, your domain-modeling needs) are such that you need
to distinguish between, e.g., different kinds of 'vehicles'
(cars vs trucks vs planes vs ...), then 'Vehicle' itself, the
common superclass, cannot be instantiable in a logically
consistent way -- it would break the idea that your concrete
classes partition the universe of discourse, if it were.

This is based on the idea of subclassing as asserting IS-A.

As, say, a Plane IS-A Vehicle, it cannot be the case (if your
concrete classes partition the universe of discourse) that
a (generic) Vehicle is instantiable; else, you would have
ambiguity in what concrete class to use to model an actual
plane -- either a concrete Plane or a concrete generic Vehicle
would satisfy all expressed constraints.  In practice, object-models
which allow instantiation of a superclass (such as Vehicle) do
so by adding a NON-expressed constraint about using the most
'leaf' class an actual object can possibly be modeled as; but,
that analysis-constraint is left non-explicitly-expressed in
the object model... it CANNOT be expressed in it.  Whatever
semantic constraints we attach to Vehicle will get inherited
by Plane, so we cannot say *of Vehicle instances* 'and this
is not specifically a Plane', else, bye-bye IS-A.

The extra constraints need to be placed in _another_ subclass
of Vehicle -- OtherwiseUnclassifiedVehicle, say.  Now *THAT*
one can be concrete -- and it will not be further subclassed.

I'm not sure I'm expressing this well, and will appreciate
it if anybody recognizes the source of this (I guess I've
absorbed this from some O-O Analysis classic, but I've looked
far and wide and can't put my finger on *which* one!).


If one accepts the idea that, at the OOA level, subclassing
is always only properly performed on abstract classes, then
of course the same idea will generalize to _multiple_
inheritance -- the (multiple) superclasses of any given
(abstract or concrete) class will all be abstract ones.

Which, in turn, tends to raise a typical issue -- are we
indeed modeling IS-A, or aren't we surreptitiously doing
PLAYS-THE-ROLE-OF by the inappropriate avenue of subclassing?

And if this doesn't lead us deep enough into troubled
ontological waters, there's the sometimes-unexpressed
meta-hypothesis behind it all -- that 'this object is
an instance of this class' is a *permanent* property of
the object; which, in turn, is why playing-a-role (which
is not permanent) is badly modeled by class-membership
(and subclassing).

In an object-system where class-membership itself is
dynamic and fluid, and new classes can be built on the
fly, change their bases ditto, have objects previously
belonging to other classes switched to them, etc, the
applicability of these criteria can be very doubtful.

Python's object system is like this, for example, though
I have not seen much actual use of this potential so
far (which fits with Python's philosophy: consistently
aim for simplicity, which, at the language level, means
not introducing constraints [any extra constraint is an
extra complication], but, at the programming level,
means 'doing the simplest thing that can possibly
work' [to quote a snippet from XP philosophy] -- not
often will 'the simplest thing' include wild abandon
in switching class-memberships around, generating new
classes on the fly, changing inheritance-DAG's at
runtime, and so on:-).


Alex