prototypes in Python [was: what is good in Prothon]

[Jonathan Gardner]

has.temp2 at virgin.net (has) wrote in message news:<69cbbef2.0405021021.7202e995 at posting.google.com>...
> > Also, it kind of renders the question, "What kind of object is this?"
> > meaningless. There are no /kinds/ anymore, at least not built into the
> > language. 
> 
> Yep. In its purest form, a proto-OO language would have only a single
> 'type' - object - and no 'classes' at all. While folk who are used to
> relying on type/class information to make their programs work may
> freak a bit at the thought of this, languages like Python and Ruby
> have already demonstrated that 'duck typing' can work well. (Again,
> it's mostly just a matter of the developer having a bit of discipline
> in the first place than relying on the compiler to pick up their slop
> after the event.

I have spent some time thinking about this and looking at my own code.
Isn't it currently discouraged to use "type" to classify objects, and
then depend on the type returned? Instead, we should look at the
actual interface to see if it implements what we need rather than
trying to force it to descend from a particular class.

Shared class data is trivial to implement in a classless system, as
you demonstrated. In fact, so is typing - just have an attribute
called "__class__" and methods for determining if a particular class
is in the inheritance tree of this object's class. We can even go as
far as to implement a system of calling the class's methods or
attributes if they are not present in the object itself. (Looks
familiar? Isn't this the way Python works right now?)

Because implementing the current Python object system in classless
objects is so easy to do, it is apparent that classless objects are a
superset (IE, contain all the features of and perhaps some more) of
classful objects. Therefore, if Python were to approach a classless
object system, it would be enhancing its featureset while being able
to simultaneously maintain backwards compatibility. (At least,
theoretically. I know that the internals of the python interpreter and
run time engine depend heavily on objects behaving the way that they
do.)

The question then becomes: Which is more programmer-friendly: classful
or classless programming?
 
The only practical limitation is that with classes, you can stuff all
the shared attributes and method into a neat package. However, with
classless, whenever you copy an object, you would have to implement
the behavior of copying all of the available attributes and methods.
How to share that data between multiple copied instances and the
original in an efficient manner is non-trivial.