ASPN ActiveState Programmer Network
ActiveState
/ Home / Perl / PHP / Python / Tcl / XSLT /
/ Safari / My ASPN /
Cookbooks | Documentation | Mailing Lists | Modules | News Feeds | Products | User Groups


Recent Messages
List Archives
About the List
List Leaders
Subscription Options

View Subscriptions
Help

View by Topic
ActiveState
.NET Framework
Open Source
Perl
PHP
Python
Tcl
Web Services
XML & XSLT

View by Category
Database
General
SOAP
System Administration
Tools
User Interfaces
Web Programming
XML Programming


MyASPN >> Mail Archive >> types-sig
types-sig
[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/)

Privacy Policy | Email Opt-out | Feedback | Syndication
© ActiveState Software Inc. All rights reserved