Getting rid of metaclasses (Was: Behaviors vs Modules)

Robert Hirschfeld hirschfeld at windwardsolutions.com
Tue Feb 26 20:26:34 UTC 2002


A while ago I started to work on AspectS, an environment to explore 
aspect-oriented programming (AOP) in dynamic systems like Squeak 
(http://www.prakinf.tu-ilmenau.de/~hirsch/Projects/Squeak/AspectS/).

AspectS can also be used to implement roles/perspectives. One of the 
differences between mixins/MI and aspects is that instead of letting 
a set of classes decide from where to inherit additional behavior, 
the aspect is responsible for adjusting existing behavior in or 
distributing additional behavior to target objects. It is just the 
other way around. Aspect instances in AspectS are regular objects 
that can change the behavior of objects in the image (all instances 
of a class or just specific ones) and revert the effects they caused 
anytime needed.

I've updated a paper that describes AspectS in more detail: 
http://www.prakinf.tu-ilmenau.de/~hirsch/Projects/Squeak/AspectS/Docs/AspectS_20020222.pdf

At http://www.prakinf.tu-ilmenau.de/~hirsch/Projects/Squeak/AspectS/ 
there are a change set and a pre-loaded image that might better explain 
what I've tried to describe in the paper...

Best,
-Robert


Henrik Gedenryd wrote:
> 
> > Goldstein and Bobrow eventually found a very interesting way to
> > implement these enriched objects: they used Smalltalk instances for
> > each role/perspective. So a PIE object could be made from many
> > Smalltalk objects.
> > This allowed each role to have its own name space of instance
> > variables. They decided that it was better to make dynamic relations
> > to unify variables that were logically the same across perspectives
> 
> I've tried both approaches to some extent (the same object and several
> objects). Several objects is much easier to implement and you can get some
> mileage from it, but I don't think it would hold up as a general language
> construct. If you really apply the perspectives idea consistently, every
> object in the system would have many perspectives, for example the whole
> meta-system would be replaced by several perspectives.
> 
> When I did this I hadn't realized that you can use a kind of selector
> namespaces to do a simple version of multiple perspectives for the same
> object. Perhaps I had gotten longer along the way then.
> 
> > Note that this interesting organization is rather independant of the
> > particular abstractions chosen for making types of instances. That
> > is, it can be used with a class-based system, or a prototype-based
> > system, or something in between (which is what I think we should
> > invent).
> 
> My tuppence would be that perspectives fruitfully may supersede both of
> these. I recently wrote a reflective algorithm that examines the structures
> of objects to find possible combinations, and realized that since this was
> perspectives-based, the reflective code wasn't "meta-level" programming as
> it would be with classes, but instead it was just the plain ol' object
> looking at a structural description itself, i.e. from a "structural" or
> "descriptive" perspective.
> 
> In a more general example, to find out the names of all of an object's
> instvars you wouldn't go to its class, i.e. the meta-level, but ask the
> descriptive perspective of the object, which knows its structure.
> 
> Another perspective would be the "prototype perspective", where you could
> e.g. ask for the "prototypical value" of some instvar, as in a default
> value, (which is what a prototype provides).
> 
> I also began sketching what the Smalltalk meta-object implementation
> (Behavior, Class, Metaclass et al.) would look like if done in this way, and
> although I didn't complete it, it seemed to become _much_ more
> understandable. Everything that the headspinning metasystem does now would
> be done by the object itself, from a few different perspectives. No more of
> those "what's the class of the Object class' superclass class" riddles.
> 
> > Just one aspect of Self.  We would still have class objects that hold
> > methods and instance variables names and a single superclass.  They
> > just wouldn't be directly reachable from globals.  And we wouldn't
> > have multiple inheritance via delegated parents.
> 
> It seemed to me that perspectives provided a good way of getting away from
> the problems of multiple inheritance. There is an Oopsla paper that makes a
> similar argument. ("The Point of View notion for Multiple Inheritance",
> 1990)
> 
> By the way, there has been a fair bit of work done on perspectives after
> PIE. The work on "roles" is also related, and of course, all that on
> subjects and aspects, too, sometimes it is more relevant, sometimes less.
> 
> Henrik



More information about the Squeak-dev mailing list