Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!ccu.umanitoba.ca!herald.usask.ca!alberta!aunro!aupair.cs.athabascau.ca!atha!decwrl!elroy.jpl.nasa.gov!usc!pollux.usc.edu!briot
From: briot@pollux.usc.edu (Jean-Pierre Briot)
Newsgroups: comp.lang.smalltalk
Subject: Re: Smalltalk MetaClass questions.
Message-ID: <31052@usc>
Date: 14 Mar 91 00:49:28 GMT
References: <9103111620.AA01484@sun.soe.clarkson.edu> <1991Mar12.214143.10980@m.cs.uiuc.edu>
Sender: news@usc
Organization: University of Southern California, Los Angeles, CA
Lines: 83
Nntp-Posting-Host: pollux.usc.edu

After the nice and concise explanation (*)
of Ralph about the metaclass architecture of Smalltalk,
I'd just like to add some pointers to alternative designs.
("Thus if you don't like it, you could change it! (Good luck!)" [Ralph #2846].)

(*: this is indeed not easy to explain reflexive systems within a single pass,
just as to implement them:-)

One alternative is the DeltaTalk design, which basically backtracks to
Smalltalk-76 architecture with a UNIQUE metaclass, named Class.
The resulting architecture is definitely SIMPLER,
BUT there are no more class methods (actually there are but they are shared
by all classes), and other (less famous: see below) possibilities of
metaclasses.
(LittleSmalltalk is even further simplified having none metaclass if I remember
well. My bibliography is out of close hand at that time).

An Empirically and Aesthetically Motivated Simplification of the Smalltalk-80
Language,
A. Borning and T. O'Shea,
ECOOP'87,
Lecture Notes in Computer Science, No 276,
pages 1-10,
Springer Verlag,
June 1987.

In an opposite direction, the ClassTalk design, keeps metaclasses, but makes
them being explicit (and not implicit as in Smalltalk).
It is also based on one unique PRIMITIVE metaclass, named Class, like in
DeltaTalk, BUT it is EXTENSIBLE (i.e., add new metaclasses).
The key is the design of Class as a self-descriptive (and consequently
instance of itself) class. This avoids the structural distinction between
metaclasses (instances of Metaclass) and other classes which leads to the
Class/Metaclass duality and complexity/opacity of the kernel.
ClassTalk has been implemented as a simulation in Smalltalk-80.
Historically it is a transposition of the original explicit metaclasses
architecture of ObjVlisp (ref. in the paper, also more ref. about so-called
reflective class-based systems, such as CLOS, and the "advanced" uses of
metaclasses).
This architecture is both simple and extensible.
However having explicit metaclasses leads to some slight incompatibilities
with the standard modeling/organization of class lattices in Smalltalk-80
(further discussed in the paper).

Programming with ObjVlisp Metaclasses in Smalltalk-80,
J.-P. Briot and P. Cointe,
OOPSLA'89,
Special Issue of Sigplan Notices, Vol. 24, No 10,
pages 419-432,
ACM,
October 1989.

I personally believe that although there were good reasons for the current
Smalltalk-80 metaclass architecture, this design does improve it.
But the standard Smalltalk-80 class lattice then needs some kind of
reorganization for a better compatibility and to fully use the new
possibilities. (This is the experience we got from our simulation
of the architecture in Smalltalk-80).
Thus it depends how you want to keep the full compatibility with
standard Smalltalk-80, and reuse the class lattice as it is, or to
propose a new improved system on many respects.
Through your description, it seems that your focus is on different
points (management of objects). On the other hand, using (various) metaclasses
to control the implementation of objects may be useful (ref. on
use of metaclasses in CLOS in the paper).

I don't want to go into more details in this followup to keep it short (failed
already!-), please see in the papers. (They should be easy to access to).

Good luck for your project, Dean. Sounds great!
Have a good reading.

Jean-Pierre Briot
LITP
University Pierre et Marie Curie
Paris, France
briot@litp.ibp.fr

currently visiting:
Dept. of Computer Science
University of Southern California
L.A., CA
briot@pollux.usc.edu