[Types-sig] Why have two hierarchies? (*EUREKA!*)

[Donald Beaudry]

Just van Rossum <just@letterror.com> wrote,
> What's the problem? ;-) (Seriously: I *may* just not get it: please
> elaborate...)

Perhaps there isnt one.  What you are suggesting reminds me quite a
bit of the type system used in Self.  Or maybe I should say that it
reminds me quite a bit of what I remember of the type system that is
used in Self.  I really need to do some reading... you could be on to
something.  (Since this is a transcontinental rant, I dont have net
access)

But, what I unsuccesfully tried to point out in my last message was
that all you are doing is renaming things.  You've proposed that what
we now call __class__ should be called __bases__ and what we now call
__dict__ should be called __namespace__.  You then proposed that we
stop referring to classes and metaclasses as such and simply refer to
them as instances.  I dont think that this renaming buys us anything.

When it comes right down to it there will be instances that must act
like the classes that we have now.  People will probably even start
calling them 'classes' to describe to others the role they are
playing.  I do like the idea that classes become more like instances
but I see no need for eliminating the term 'class'.  Likewise, as
classes become more like instances, they too will be associated with a
class object.  But, this class object will be quite a bit different
from the class objects we know today.  Rather than existing for the
purpose of creating new "instances", they will exist for the purpose
of creating new classes.

I can understand your desire to simplify this whole mess.  Some of
people reading this list are familar with my unsuccessful attempts to
explain what I consider to be a very elegant and simple concept.  The
concept being that all objects should be alike in some very
fundemental ways.  Unfortunately, the implementation of this
"everything is a turtle" approach has some interesting implications.
The are also some interesting implications associated with being a
raving lunatic who tries to explain simple concepts. (Yes Gordon, I've
given up on trying to hide it, you were right all along ;)

To be honest, I dont even understand the subject line in this thread.
What are these two hierarchies anyways?  Are you referring to the type
vs class hierarchies or the meta vs non-meta hierarchies?  Personally,
I dont belive in the need for either of these splits.

The type vs class issue is simply an artifact of the current
implementation.  Quite a while back, the MESS tried to show the world
that this was indeed the case.  In the MESS, both type objects and
class objects exist, but belong to the same heirarchy.  That is, class
objects are derived from type objects, therefore, a class object
*is-a* type object.  The useful distinction between the two objects is
that type objects are used to describe objects that have been
implemented in C while class objects are used to describe objects that
have been implemented in Python.

As for the meta vs non-meta hierarchies, they too are derived from a
common base so are in fact part of the same hierarchy.

I think too, that it's at least slightly interesting to point out that
from the start the Python implementation has recognized the need for
the existance of a "meta-entity" by way of the Typeobject.  For some
strange reason, the fact that the Typeobject is an instance of itself
has not been known for causing any heads to explode.  It's a very
simple and useful idea.  The mergeing of all of this into a single
style for the creation of objects is simply an extension of the
capabilities of the current Typeobject.

In my opinion, the interesting questions have to do with the interface
to the interpreter (the C API) and the interface to the user (the
Python syntax).  In the past, the primary complaints about my
proposals have centered around the notion that what I am asking for is
too powerful or too general, and therefore to difficult to explain and
understand.  While those issues dont bother me, I will agree that the
complaints are valid.  The excess generality should trimmed.  The
power should be restricted.  So, how do we do this?  What should be
do-able from the C API?  What should be do-able from Python itself?

Perhaps much of this has already been covered, if so, I'll apologize
now for not having read much of what has been posted to this list.
I'm trying to catch up.

	--Don