Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!exodus!sbb
From: sbb@laplace.eng.sun.com (Steve Byrne)
Newsgroups: comp.lang.smalltalk
Subject: Re: Smalltalk MetaClass questions.
Message-ID: <SBB.91Mar11131805@laplace.eng.sun.com>
Date: 11 Mar 91 21:18:05 GMT
References: <9103111620.AA01484@sun.soe.clarkson.edu>
Sender: news@exodus.Eng.Sun.COM
Organization: FSF hackers, Smalltalk division
Lines: 52
In-reply-to: dean@sun.soe.clarkson.edu's message of 11 Mar 91 16:20:45 GMT

In article <9103111620.AA01484@sun.soe.clarkson.edu> dean@sun.soe.clarkson.edu (Dean Swan) writes:

   Path: exodus!newstop!sun-barr!cs.utexas.edu!usc!rpi!clarkson!sun.soe.clarkson.edu!dean
   From: dean@sun.soe.clarkson.edu (Dean Swan)
   Newsgroups: comp.lang.smalltalk
   Date: 11 Mar 91 16:20:45 GMT
   Lines: 45


   I'm working on an implementation of Smalltalk, designed to work with large
   disk based images, and run on machines with limited primary memory (i.e.
   640k MS-DOS machines, and the like).

   I will probably base my class hierarchy on that delivered with GNU Smalltalk,
   which means that my implementation will ultimately end up as "free software".
Wonderful!!!

   ...

   Now, on to my question:  Could someone be so kind as to explain the workings
   of the Behavior, Class, MetaClass hierarchy?  I've read the Blue Book, traced
   through Smalltalk/V, and GNU Smalltalk, and I'm still thouroghly confused.

   As I understand it, each instance of MetaClass corresponds to a 'real' Class,
   but in Smalltalk/V, Class has no instances, and no subclasses, so how are
   it's instance methods ever reached?  Behavior makes sense in that it just
   defines a common protocol for Class and MetaClass.

Stare at the complex complete class (and metaclass) diagram in the blue book.
It takes time to figure out how things are arranged.  At least it took me a
while before I was comfortable with it.

   Question #2:  What is the purpose of this convoluted Behavior, Class,
		 MetaClass thing?  What does it do for you?

It makes the entire class system well defined in the sense that by exploring
the class hierarchy you won't get to a point at which you get a non-object as a
return value from a method.  There are other ways to design the class hierarhcy
so that this is not required, but this is the "purest" in many respects.

Some places the class and parent class hierarchys are deliberately looped back,
such as Object class ==> Class; this is an example of this closing of the
inheritance hierarchy (here "closed" is used in the algebra sense of "closed
under addition").

I know it's confusing...but if you stare at the diagram and read the rules (1-7
just before the complex diagram) long enough, it will begin to make sense.
It may also be helpful to think about how you'd set things up differently ...
if you think things through well enough, you'll see the points at which it's
logical to do the things that the Smalltalk designers did.

Steve