Smalltalk and Python

[Alex Martelli]

"Ian Wild" <ian at cfmu.eurocontrol.be> wrote in message
news:3A38CF3E.8BBD2216 at cfmu.eurocontrol.be...
> Alex Martelli wrote:
> >
> > Forget C++ -- we're talking OO _analysis_.  Assume you're
> > trying to perform OOA on the universe of discourse "immutable
> > planar 2D geometric polygons", for the sake of definiteness.
> >
> > If Rectangle and Square are both concrete (instantiable)
> > classes, with *overlapping* requirements for membership,
> > how do you classify a given rectangular object which
> > happens to have equal sides?  Toss a coin?
>
> Both.
>
> Unless you're using classes purely as an implementation
> shortcut, why need an object be a member of precisely *one*
> class?

Because that's how object-oriented analysis works -- at
least, all OOA methodologies I've ever encountered.  Please
supply references to OOA methods working differently --
they'll surely be interesting to study.  (If you don't
have any such reference, then go away for a while, write
up your new and brilliant 'one object -> many concrete
classes at a time' OOA methodology, have Addison-Wesley
publish it, make a mint as it sweeps away all the old and
dusty 'one object -> one class' alternatives and you
become the most sought-after consultant in the industry,
THEN provide the reference, thanks).


> What if your analysis is later implemented in
> a language without classes (eg Self?), or one where
> classes exist only by convention (Perl)?

'only by convention'!?  Have they abrogated the 'bless'
keyword, now?

Anyway, when I do OOA (and sometimes OOD), and then
have to implement the results in a non-OO language,
or a language whose object-model is miles apart from
that implied in the OOA/OOD methodologies I have
chosen to employ, then I may have more bridging to do
than if the object models were a good match for each
other (each at the appropriate level of abstraction).
So what else is new?

I fail to see any benefit in a methodology assigning
each object to several concrete-classes, as opposed
to one identifying _interfaces_ (abstract classes),
and working along classical lines -- each object is
in a (one!) class, each class implements N interfaces,
etc.  This is a good match for the object models in
COM, Java (though you may have to further identify a
pattern of implementation inheritance then -- but this
is clearly a later issue, for design-time), .NET/C#
(ditto), Sather -- and easily implementable in languages
with richer class-structures, such as Eiffel and C++
(and in languages without a formalized concept of
'interface', such as Smalltalk and Python, where
one just defines the interface as a bunch of related
messages an object 'implementing the interface' will
appropriately respond to -- typical dynamic vs static
typing dichotomy).  I don't have enough practical
experience in OO design/coding in Self or Perl to be
sure, but I'd bet it wouldn't be beyond what's easy
in those languages, either.

What compensating advantage does your favourite
'many-CONCRETE-classes-per-object' OOA approach
offer, to offset its serious mismatch with many
available implementation-languages object models?
I can't see any, but am I just being short-sighted...?


Alex