About reflection and it engineering

Trygve Reenskaug trygver at ifi.uio.no
Thu Nov 6 08:39:33 UTC 2003


(ahh, one of my favorite topics, too)

In UML, as in Smalltalk, there are two independent structures of classes: 
inheritance and instantiation, «kindOf» and «instanceOf».
http://heim.ifi.uio.no/~trygver/2002/uml-vm/01-21-UML_VirtualMachine-131.pdf
shows the four layers of the four UML «instanceOf» layers and the five 
corresponding Smalltalk layers. In
http://heim.ifi.uio.no/~trygver/2003/umlStatic/index.html
you will find an unofficial poster showing package and class inheritance 
diagrams for the static part of the brand new UML: UML 2.0. I have a 
diagram on my wall and refer to it frequently. Not to find answers, but to 
find ideas that I can use.

The five Smalltalk (VW) layers are:
         app object, e.g., 'Mike'
         app class, e.g., Person
         app metaclass, e.g., Person class
         Metaclass
         Metaclass class
the two last ones are instances of each other. So technically, VW has a 6 
layer instantiation architecture.

As you say, there is immense power here. But you may, in places, be 
confusing the instantiation and inheritance structures. You can make a new 
kind of Account by making a new class, perhaps subclassing an abstract 
account class. But what if I want some static typing in my banking 
programs? I need a new Metaclass that gives me classes with a new kind of 
attributes. The instVar 'instanceVariables' in these classes will be an 
array of attribute objects that hold typing and other information. And the 
behavior of these classes, including the compiler, will be different to 
utilize the new information.

The Object Management Group (OMG) is using the power of its layered 
instantiation architecture to define diverse modelling languages such as
         UML - Unified Modeling Language
         MDA - Model Driven Architecture
         MDD - Model Driven Development.
All languages are defined by their metaclasses, all ultimately instances of
         MOF - Meta Object Facility

Most OMG people are not Smalltalkers. So it is unclear to most of them what 
their powerful architecture really implies. But the Squeak community could 
help them understand what UML 3.0 should really be like. Remove the 
distinction between build time and run time. Downplay the importance of 
packages, static name spaces, class inheritance, etc. Understand what is a 
module in a world of objects, how to manage dynamic loading, avoiding 
environment conflicts. How to live in an evolving world. Most of them hot 
topics in the Squak community. I'm sure we can give significant 
contributions. We are talking about a world of interconnected Dynabooks, right?

--Trygve

At 05.11.2003 15:21, you 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


-- 

Trygve Reenskaug      mailto: trygver at ifi.uio.no
Morgedalsvn. 5A       http://heim.ifi.uio.no/~trygver
N-0378 Oslo           Tel: (+47) 22 49 57 27
Norway





More information about the Squeak-dev mailing list