Path: utzoo!news-server.csri.toronto.edu!rutgers!usc!rpi!clarkson!sun.soe.clarkson.edu!dean
From: dean@sun.soe.clarkson.edu (Dean Swan)
Newsgroups: comp.lang.smalltalk
Subject: Smalltalk MetaClass questions.
Message-ID: <9103111620.AA01484@sun.soe.clarkson.edu>
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".

My implementation is most likely to be completely interpreted, except for a
minimal set of primitives, due to the nature of my storage manager, which
uses no object pointer table, and is not based on absolute pointers either.
My storage manager *does* however, support incremental garbage collection,
and fast object lookups without using generation scavenging, or reference
counts.  It also incorporates image compression automatically, so
redundant chunks of memory are minimized.  The virtual machine "runs" the
compressed image, not an uncompressed copy.

My motivation for this project: dBase sucks.  I'm intending to use the
finished product to produce large information systems, based on a large,
persistent object space.

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.

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

I've got my storage manager designed, but the design is incomplete at this
point, because some of it's operation must be dependent on the structure of
the virtual image.

I'd appreciate any and all help that anyone can offrer on this problem.
E-mail replies would be preferred, and I can post a summary.

The sooner I understand this, the sooner I can finish this thing, start
using it, and give it to people.

-Dean Swan                          Independent Software Consultant
dean@sun.soe.clarkson.edu           Tel: (315) 265-2679