Python 1.6 The balanced language

[Alex Martelli]

"Neel Krishnaswami" <neelk at brick.cswv.com> wrote in message
news:slrn8r4qej.b6p.neelk at brick.cswv.com...
> Alex Martelli <aleaxit at yahoo.com> wrote:
> >
> > "subtyping exists" is another contentious issue, of course; if I
> > removed "extends" from Java, requiring all polymorphous use to
> > go through "interface" and "implement" (as, e.g., Coad has suggested
> > as best design practice), would I "totally lose OO-ness"?
>
> No, because you still have subtyping. You've taken away inheritance,
> but that's not the same thing (see Sather for a rather graphic
> illustration of the difference).

If by subtyping you mean the java 'implements', then, yes.  But to
call the signature-based polymorphism of Python "subtyping" is
starting to stretch the meaning of the word -- yet, it's at least
equivalent to what interface+implements lets you do, modulo
the compile-time checks.

I say that OO == polymorphism, aka, runtime dispatching.  If
it's done through subtyping, signatures, prototypes, etc, is quite
a secondary issue.


> > Are languages based on 'prototype objects' (with no classes at all)
> > "not OO"?  Pah...
>
> You still have types as a semantic concept in Self and Cecil, though.
> A type object is one which other objects name as a delegate; grab all
> the objects that delegate to it and you have all its direct instances.
>
> The fact that an object's type can change over its lifetime isn't a
> disqualification. Note that this isn't that foreign to Python, either:
> you can change an object's class by setting the __class__ field, and
> you can change the inheritance graph by setting __bases__.

In Python, a class object plays a very specific role -- it knows it's
a class, its role in life is to generate instances and provide a shared
namespace/dictionary for them.  An object which is named as a
delegate in Self has no such specialness.  Similarly, say the Cecil
authors, "Cecil uses a classless (prototype-based) object model"
(e.g., cfr http://www.objs.com/x3h7/cecil.htm).  And one must
not confuse argument-specializers, with type-declarations (the
latter do not affect method-lookup in Cecil).

Are you saying that they're wrong, that it's NOT 'classless'?  Or do
you accept that claiming 'classes' are a prereq for O-O, as the
poster I was responding to did, is simply wrong?

Of course you can identify at any moment in time various sets
of object-instances that have something in common (e.g, they
all delegate something to a given object X; or, they all happen
to live entirely on a given page of virtual memory; or, they're
all referencing a certain string S; etc, etc).  But to call such
sets 'types' (whatever rule you choose to identify the dynamically
changing set[s]) is not particularly enlightening -- and to call
them 'classes' is worse... 'disinformation'!-)


Alex