Tom Ayerst wrote:
> 
> I'm posting this here because The People Who Know are here (and it's
> friendly).
> 
> During a recent thread on comp.lang.smalltalk on public methods and
> private methods I realised (again) that I didn't understand smalltalk.
> My original epiphany (like many others) was realising that branches and
> loops were achieved via polymorphism, not special syntax.  My second was
> that smalltalk only works with objects and messages (Now I knew that
> before, I just didn't 'know' it) and this was why the concept of private
> members, public methods was a little irrelevant to smalltalk (it just IS
> that way).
> 
> Now I thought I had a handle on it but I did an experiment, ending a big
> sequence of 'class' messages, and I'm confused again.
> 
> I started with Association and got:
> Class                        self                          superclass
> -----------------------------------------------------------------------
> Association               self $a->1               -
> Association class       Association             LookupKey
> Metaclass                 Association class     LookupKey class
> Metaclass class         Metaclass               ClassDescription
> Metaclass                 Metaclass class       ClassDescription class
> Metaclass class         Metaclass               ClassDescription
> 
> after that its turtles all the way down.
> 
> So, does this mean that the instance (first level) only holds state
> information?
> The Association class object (second level) holds the methods (and class
> members I expect).
> The instance of Metaclass (third level) holds the Association class
> methods.
> After that we are in metaclass land.
>
> The confusion arises at the first level which only holds member
> variables (pure state).  Each object instance is very small (just
> members) and the methods are held in a dictionary in the object's class
> object (second level) which is a singleton.  Now is this an efficiency
> thing?  Should the methods logically be associated with each instance
> but to make it work they are in the class object?


That might be one way to look at it- in fact, the language Self took the
instance-based approach ( while retaining a heritage with Smalltalk as
it's ancestor ).  You might think of Smalltalk allowing you to tackle
a design problem from an instance-oriented point of view, and then at
a certain point in your understanding of the problem recognize that many
instances are similar- that is, are members of a particular Class.  In
that sense, the class exists as a means for easily managing the
methods of a large number of similar instances.  Classes actually have
at least three primary roles, which in other languages are usually separated
into various language constructs ( in Smalltalk of course, they are each
represented by an object, and in this case, the same object for all three ):

	1) provide the structural pattern
	2) provide the behavioral pattern
	3) act as the factory for its instances.

In addition, it often has other roles as well- for instance, in some
cases I have the class act as sort of a shephard for it's instances-
that goes beyond the call of duty described by (3).  Actually,
this extra role one played by the Metaclasses with respect to
their sole instance, the class for which they provide methods ( which in
turn provides the methods for "regular" or "instance" objects ) - Metaclasses
must be sure that in fact they have only one instance. ( classes are instances
too, you see - but few instances are also classes. ).

It might help to realize that what we call the class hierarchy is in
fact not one but TWO parrallel hierarchies- one, consisting of the classes
which provide methods for the objects ordinarily called instances, and
the second consisting of the metaclasses which define the methods used
by the objects ordinarily called classes ( all objects have classes, 
in smalltalk everything is an object, therefore all classes have classes,
and those classes are called the metaclasses, which are objects which
happen to all be defined by a single object, the class called Metaclass,
whose class is Metaclass class, and if you are still following this,
the class of Metaclass class is - Metaclass.  This is the loop that throws
people, though not the only bit of monkey business in this whole affair
that is odd- the other bit of oddity happens at the roots of these
two hierarchies- but it would be best for you to get a good book
and study the pictures carefully- words will only tangle the picture. ).

FWIW, although I have not tried this I believe that it is possible to do
instance-based programming in nearly all Smalltalk dialects- I believe that
there are no VM-level constraints that would prevent you from deciding that
the object which will provide the behavior of a particular object will in fact
be that object, rather than some other object which we would ordinarily call
that object's class.  There are no tools supporting this, but I think it
can be done.


> Now if we consider the Association class object as the first level then
> this includes the method dictionary as a member variable (pure state).
> (This is where I got all excited again).  So everything really IS an
> object and reflection is just sending messages to objects that happen to
> define the system.

YUP.  Amazing how simple that is when it's done right!  The big question
is how did they get that ship in the bottle in the first place...


> If someone wouldn't mind, can they confirm that I have not just made a
> complete fool of myself by getting it all wrong.


No- you're running into a singularity that exists within the class hierarchies.
Sounds like the timing is just about right for you to hit this one.  Actually,
there are certain things about this that I find puzzling even now.  Liu's
Smalltalk book has an excellent discussion about the circular relationship
that exists between Metaclass and Metaclass class ( they define the behavior
for each other ).  Beyond that, all I'll say is that some very twisty things
appear to happen, although that is an illusion- it turns out to be very straightforward.

( I think Liu's book is "Objects and Design", but that's from memory ).

So, to sum up- don't sweat, most Smalltalkers go for years without ever worrying
about this, and it is very unlikely to ever come up as being an issue in your
own programming design.

> Thanks.
> 
> Tom
> 
> P.S. Methinks its time to read Smalltalk-80 that has been languishing on
> my shelf.


Good luck - if the explanations I've given appear confusing, don't be too worried
about it- this is one of the most difficult to understand aspects of the whole
Smalltalk world, and pretty tough to describe without confusing the daylights out
of people.  "Get a good book" is the best answer...

- les