(ahh, one of my favorite topics)

I agree with Jecel from a concrete instance perspective, but from a more
abstract perspective (including the fact that metaclasses and Metaclass are
implemented using classes and instances) you really only have three
metalevels implemented in Squeak:

-Instances (objects having private data, shared structure and shared
behavior (via their common class))
-Classes (objects that are instances, but then define the shared structure
and behavior for a lower metalevel of their instances)
-Metaclasses (objects that define the structure and behavior for a lower
metalevel of their instances (which in fact are classes)

In Smalltalk, metaclasses are instances that model classes, and Metaclass
is the class for all models of classes.

Of course, we can't have "turtles all the way down", so Metaclass itself is
modeled and implemented by subinstances of itself.

It is amazing how much value we have recieved from this model, but as Alan
has mentioned on occasion, we have rarely revisited Metaclass or thought of
its potential siblings.

Years ago when I taught lots of classes on Smalltalk, someone in each class
always asked the "so what is the class of a class of a class?" question.
Its not necessary to understand the answer to get lots of value from
Smalltalk, but a thought vacation to metaland can be very interesting.  It
can also give you a powerful lever on design complexity in many domains.

<meta-meta-meta-meta>
Consider that there is effectively only one Metaclass in Squeak, in that
all classes have a fixed set of ways to define their structure and behavior
and that of their instances.  But that one Metaclass defines the entire
universe of all classes and instances directly implementable in Smalltalk.
(Of course, you can use Smalltalk to indirectly model almost any concept,
but not directly in the sense that you have to create a simulacrum of your
concepts using the Smalltalk concepts of objects, instances, classes,
messages, methods, etc.)

Now can other kinds of Metaclass exist?  Of course they can, and each would
provide a definition for an entirely separate universe of classes and
instances parallel to the currently Smalltalk universe.  For example, a
class system where all classes must have two and only two superclasses, and
are limited to integer instance variables and unary messages.  At this
metalevel you would find Metaclasses that define entirely distinct object
systems, including lots of those other "object" languages.

If we then can have lots of sibling Metaclasses, what might their class
look like?   <brain hurts>   and their class?   <brain turns to mush>

A practical application of this meta-mumbling can be found in many
applications and be straightforwardly implemented in Smalltalk.  It is not
uncommon to have real world domains that have their own class-instance
relationships *in the domain*.  For instance, a bank offers several kinds
of account services, say checking and savings.  You can directly implement
two account models, perhaps using inheritance to save a little recoding,
and you have your system.  You can have CheckingAccount and SavingsAccount
classes, and their instances will hold the account data for each customer.
Note that you have specific classes modeling specific account types and
their instances modeling accounts.

But what happens when the bank wants to add money-market accounts?  You can
of course model those in Smalltalk and add new code, but what if your bank
wants an application that allows it to create new kinds of accounts on the
fly with no new programming?  This leads to a situation where many projects
have created horrendously complex classes that attempt at once to model
both the class-ness and instance-ness of the domain in the same object.
Big mistake.

What you have here is a situation where you need a "metaclass" of sorts
that lets you define new types of accounts which can then have individual
customer accounts based on them.  You have the same
Metaclass-Class-Instance relationships that exist in the Smalltalk system,
but you are implementing them on top of the existing Smalltalk system,
using its classes and intances. Confused yet?

To be more direct, you create a class (say AccountType) in Squeak whose
instances are different types of accounts, and then create a class (say
Account) in Squeak whose instances are the individual accounts themselves,
but act as if they were instances of the instances of AccountType.  The
AccountType instances would define the structure(data) and
behavior(policies, notifications, etc) for the Account instances.  Each
Account instance would upon creation refer to its AccountType "class" for
details of what kind of private data structure (variables) to construct.
During later execution, the Account instance would refer to its AccountType
"class" for its behavior, which would be shared across all Acount instances
referencing the same AccountType "class".

There is *lots* of programming power in this approach, and for all its
inherent complexity, it can dramatically  reduce the complexity of
competing designs suffering from "domain class-instance confusion".  This
approach has been proven many times in systems ranging from global trading
to semiconductor manufacturing to custom billing systems to not-a-few AI
applications.  It takes some work to wrap your head around it, but its well
worth the effort.
</meta-meta-meta-meta>

Regards,
Sam


Sam S. Adams, IBM Distinguished Engineer, IBM Research
tie line 444-0736, outside 919-254-0736, email: ssadams at us.ibm.com
<<Hebrews 11:6, Proverbs 3:5-6, Romans 1:16-17, I Corinthians 1:10>>



|---------+--------------------------------------------->
|         |           Jecel Assumpcao Jr                |
|         |           <jecel at merlintec.com>             |
|         |           Sent by:                          |
|         |           squeak-dev-bounces at lists.squeakfou|
|         |           ndation.org                       |
|         |                                             |
|         |                                             |
|         |           11/05/2003 01:13 PM               |
|         |           Please respond to The             |
|         |           general-purpose Squeak developers |
|         |           list                              |
|         |                                             |
|---------+--------------------------------------------->
  >---------------------------------------------------------------------------------------------|
  |                                                                                             |
  |       To:       The general-purpose Squeak developers list                                  |
  |        <squeak-dev at lists.squeakfoundation.org>                                              |
  |       cc:                                                                                   |
  |       Subject:  Re: About reflection and it engineering                                     |
  |                                                                                             |
  >---------------------------------------------------------------------------------------------|




On Monday 03 November 2003 18:50, ducasse wrote:
> On Lundi, nov 3, 2003, at 15:04 Europe/Zurich, Serge Stinckwich wrote:
> > Do you know why the authors call Squeak a 5-metalevel system and
> > Little-Smalltalk a 3-metalevel system ?
>
> No I read that too.

It is unlikely I will find time to read the paper this year, so I could
be totally wrong. But the original Little Smalltalk used:

  instance ==> class ==> Class

while Squeak has

  instance ==> class ==> metaclass ==> Metaclass ==> Metaclass class +
                                          ^                          +
                                          +==========================+

The three level system was also used in Smalltalk-76. You can't have
class variables and such with it, which I don't think is such a huge
loss. Anyway, I think Little Smalltalk has since "evolved" to a more
complicated system.

-- Jecel