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
squeak-dev@lists.squeakfoundation.org