[Types-sig] Re: Type/class unification
by Vladimir Marangozov other posts by this author
Nov 27 1998 4:11AM messages near this date
RE: [Types-sig] Why I don't like static types in Python
|
[Types-sig] Type/class unification
Forgot to include Guido's masterpiece (and save you digging egroups).
--
Vladimir MARANGOZOV | Vladimir.Marangozov@[...].fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252
From: Guido van Rossum <@CNRI.Reston.VA.US>
Subject: [python-classes] ASCII art
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
I've been working on a response for days now, and I'm giving up.
Instead, I'll try to draw some stuff that I drew on a whiteboard today
in front of a bunch of Norwegian and local Pythoneers.
Consider instance x of class C, derived from class B. This is the
ideal diagram:
+-----------+
| x |
+-----------+
|
|
v
+-----------+ +-----------+
| C |----> | B |
+-----------+ +-----------+
\ /
\ /
v v
+-----------+
| class |
+-----------+
I use the following convention: an arrow pointing down goes from an
object to its meta-object, class or type. An arrow pointing right
goes from a class to its base class.
The idea is that you follow the down arrow to get to an object's
behavior -- so x's behavior comes from C, and C's behavior comes from
'class' (and so does B's). You follow the arrow right to delegate
attributes to a base class. (With multiple inheritance, you draw
multipl arrows.) Note that the delegation from C to B will allow x to
find behavior in B if it isn't found in C.
In the current CPython implementation, things look a bit different:
+-----------+
| x |
+-----------+
/ |
/ |
/ v
/ +-----------+ +-----------+
/ | C |----> | B |
/ +-----------+ +-----------+
v \ /
*===========* \ /
I instance I v v
*===========* *===========*
\ I class I
\ *===========*
\ /
\ /
v v
*===========*
I type I
*===========*
That is, x has *two* behavior-defining links: one to the type
'instance', one to the class C. (I've drawn type objects in a
different style here.) This is what causes a lot of grief.
I'd like to move to the first diagram. It can be extended downwards
and to the right. You could have as many levels of metaclasses as you
want, and it would all be well defined: behavior comes from below,
delegated behavior from the right.
I've got to go soon, and I want this to go out tonight, so I'll just
add some quick notes.
- I like David's idea of specifying the metaclass in the class
statement. Specifying the base class is specifying the arrow to the
right; specifying the metaclass is specifying the arrow down.
- There is a difference between class methods (which specify behavior
of the class, and are defined in the metaclass) and C++/Java style
static methods (which should be defined in the class using a special
syntax so that they don't belong to a specific instance; however, as
in C++/Java, it should still be *possible* to invoke them via the
instance, as well as via the class.) [I had a longer rant about this,
but no time to condense it now.]
- There could be a class "Object" which is used as the default right
arrow.
- There could also be a class "Turtles-all-the-way-down" which is used
as the default arrow down.
- I don't know if Object and Turtles are the same object. I know that
each has a right arrow to Object and each has a down arrow to Turtles;
they *could* be related like this:
------- --------- ------------------
| | | \ | |
| v v \ | |
| +---------+ \ \-> +--------+ |
| | Turtles |-------------> | Object |---/
| +---------+ \ +--------+
| | \ |
\ / \ /
---------- --------
(Heh! :-)
- There are plenty of problems left. Later, after my drumming class :-)
--Guido van Rossum (home page: http://www.python.org/~guido/)
|