See also things done by Noury Bouraqadi (using mixins for metaclass  
composition - see the ESUG Academic Track page for the papers on  
http://esug2003.esug.org/academic.htm) and related work by us using  
Traits for the same purpose (mail me for the reference; it is submitted  
but not yet published).

On Wednesday, Nov 5, 2003, at 21:21 Europe/Zurich, Sam Adams wrote:

>
>
>
>
> (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
>
>
>
>
>
Roel Wuyts                                                               
   DeComp
roel.wuyts at ulb.ac.be                               Université Libre de  
Bruxelles
http://homepages.ulb.ac.be/~rowuyts/                                     
Belgique
Board Member of the European Smalltalk User Group: www.esug.org