Alan,

The ideas of having multiple roles/views/perspectives associated to an object sounds very interesting and promising. I'd really like to know more about these PIE system and its implementation. If you have any pointers to some information, please let me know.

Thanks, Nathanael

-----Original Message----- From: squeak-dev-admin@lists.squeakfoundation.org [mailto:squeak-dev-admin@lists.squeakfoundation.org]On Behalf Of Alan Kay Sent: Sonntag, 24. Februar 2002 20:18 To: squeak-dev@lists.squeakfoundation.org Subject: Re: Getting rid of metaclasses (Was: Behaviors vs Modules)

Yes, they were done after I left and, as I have written before, IMNHEO do not pay for their added complexity.

However, I have been in favor of the late 70s PARC "multiple perspective" way to make objects that was pioneered by Ira Goldstein and Danny Bobrow in their PIE system (the most interesting extension of Smalltalk that I've seen). The thrust of this model is that objects have multiple roles/views/perspectives -- for example, from the outside, many objects in Squeak could be dealt with as playing a graphics role, a collection/valueholding role, an object role, and various roles with the objects it relates to (e.g. it could play any or all of: a parent role, an offspring role, a teacher role, a student role, a manager role, and employee role. etc.). These roles are all additive "sideways" relationships. 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 (as opposed to mapping all the variables of all the perspectives into a single Smalltalk instance and dealing with the possible clashes).

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).

Cheers,

Alan

---

At 12:42 PM -0500 2/24/02, Anthony Hannan wrote:

...

Nathanael n.schaerli@gmx.net wrote:

...

• A mixin may contain a meta-mixin which defines class side behavior.

I was leaning towards getting rid of metaclasses. A class reference like "String" would instead reference the String prototype, and class methods would be moved to instance methods under an appropriate category like "instance creation". Class variables can be replaced by instance methods that store arbitrary constants, instead of just literals. This allows overriding without the need to use class instance variables. And the prototype can serve as an example (enhancing documentation) or as a real prototype to copy. The prototype (or any instance) would respond to #new the same as today by creating a brand new instance. It would respond to #copy by copying itself. So the user has a choice.

--

Jim --

Did that book also have the "Officetalk" paper from PARC, by William Newman, Dan Swinehart, Tim Mott, etc.? That was an amazing blast from the past.

P.S. I have the four PIE papers. Maybe I should try to .pdf them and put them online (might take awhile though). I did write Danny Bobrow to see if anyone else had already put them online.....

Cheers,

Alan

-------

At 8:46 PM -0800 2/24/02, Jim Benson wrote:

Nathanael,

...

The ideas of having multiple roles/views/perspectives associated to an object sounds very interesting and promising. I'd really like to know more about these PIE system and its implementation. If you have any pointers to some information, please let me know.

The only place I've seen any of this written up was in the book Interactive Programming Environments [1984] edited by Barstow, Shrobe, Sandewall, ISBN 0-07-003885-6. PIE is written up as "A Layered Approach to Software Design" by Goldstein and Bobrow. pp 387-413. This paper was originally published as Xerox Parc CSL-80-5.

Whenever I want to be depressed, I just pick that book up and start reading. It represented the state of the art in '84, and it's amazing how little things have advanced since then.

I haven't found anything online, but I hoped that this information might help.

Jim

--

Alan,

Did that book also have the "Officetalk" paper from PARC, by William Newman, Dan Swinehart, Tim Mott, etc.? That was an amazing blast from the past.

No it doesn't, I've never seen that one. It sounds very interesting, something I would like to see.

However, "Interactive Programming Environments" does include what at the time (like even now) were pretty interesting ideas. One section is called "Artificial Intelligence in Interactive Programming Environments" which talks about things like the Lisp Programmer's Apprentice and knowledge based program editing. That approach is something like "Here's an outline of my problem, suggest a code solution for me".

PARCs Warren Teitelman wrote up several articles on Interlisp. I remember being fascinated at the time by "A Display-Oriented Programmer's Assistant" which contained references to a 'Do what I mean' facility, which is a different flavor of the Smalltalk Transcript/Workspace/Debugger/cascading menus environment. Teitelman goes through a couple of programming examples in the Interlisp environment, and how the integration of the environment leads to an easier to use system. As an example, he's programming away in a Transcript Workspace and Debugger and INFORMAIL tells him he has an important email to read, so he pulls up the email, responds, and resumes debugging. At the time *I* was trying to poke a character into a PCs display buffer in assembler, and trying to figure out how I was going to afford to upgrade from a 160K floppy drive to one of the nice, new, big 360K drives for *all* my long term storage needs. You've noted that perspective is worth 100 IQ points (I agree entirely), I've noticed that having a "big boy" machine and the right tools can change your perspective in a hurry. Fortunately that machine dichotomy isn't nearly as bad now as it was then.

Adele Goldberg has a Smalltalk-80 paper, "The Influence of an Object-Oriented Language on the Programming Environment" in the book, and Richard Stallman extolls the virtues of something newish at the time called "EMACS: The Extensible, Customizable, Self Documenting Display Editor". Kernighan wrote up the UNIX programming environment. The last two didn't sound very useful to me in comparison to what other people in the book were doing. There are a couple of LISP Machine papers by Greenblatt et.al., and Winograd has his say in a couple of papers.

A blast from the past to be sure, but I'm surprised about how little the programming task has changed over the last twenty years, and how little modern programming environments help construct reasonable programs in a timely manner. My take on this area has mostly been that the machine should know more about nuts and bolts programming than I do. That should include not only conceptually simple minded things like "make my code run faster", but also "programmer coaching".

Jim

Hi Alan,

I'm pleased that you favor bringing up the subject of roles / aggregation / composition again.

On Sun, 24 Feb 2002, Alan Kay wrote:

Yes, they

(metaclasses)

were done after I left and, as I have written before, IMNHEO do not pay for their added complexity.

However, I have been in favor of the late 70s PARC "multiple perspective" way to make objects that was pioneered by Ira Goldstein and Danny Bobrow in their PIE system (the most interesting extension of Smalltalk that I've seen).

Thank you for this evaluation!

  The thrust of this model is that objects have multiple 

roles/views/perspectives -- for example, from the outside, many objects in Squeak could be dealt with as playing a graphics role, a collection/valueholding role, an object role, and various roles with the objects it relates to (e.g. it could play any or all of: a parent role, an offspring role, a teacher role, a student role, a manager role, and employee role. etc.). These roles are all additive "sideways" relationships.

  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 (as opposed to mapping all the variables of all the perspectives into a single Smalltalk instance and dealing with the possible clashes).

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).

Cheers,

Alan

I would like to see Squeak beeing developed into this direction. Actually this point reminds me of a slightly polemic discussion initiated by Stephane Ducasse last June about the class Morph having about 1000 methods. (The thread: http://aspn.activestate.com/ASPN/Mail/Browse/Threaded/squeak/573455)

In particular I had asked Ned Konz in that thread about the problems of understanding how the class Morph works and the conclusion was IMO that the problem arises from the fact that the class Morph is an aggreation/composition of many roles which are not easily seen.

Some of a Morphs many roles are summarized in

(Ned Konz) http://aspn.activestate.com/ASPN/Mail/Message/squeak/619572

It all depends on what a Morph is supposed to be able to do. Note that

one of

the reasons that Morph got bigger was that specific functionality got

moved

into it:

• any morph can be a button (not just *Button*Morph classes)
• any morph now knows how to do fancy layout (not just AlignmentMorph)
• any morph can be dropped into a piano roll
• morphs know how to print themselves
• morphs have an extendable set of halos

etc. There's a lot of functionality that *any* morph possesses that

would be

hard or inefficient to reorganize. Some of this has already been done

(like

with layout policy objects).

I think Ned stated the problem in a good way in the last message of that thread

http://aspn.activestate.com/ASPN/Mail/Message/squeak/619684

I remember that Scott Wallace likes having base objects which can do a lot because they are easier to extend. And I think you have written that you like massively polymorphic objects as well. In the meantime I began to appreciate this idea which I was opposed to from a more classical software engineering point of view. (Actually there it is an indication of bad design.)

For the user (includes "application" programmer as user) it is conceptually nice to have objects which can do many things.

From the student, fix, enhancement, research programmer point of

view one would like that the system is easier to understand. In Java for example people think this is resolved in adding more and more classes but I think it is difficult there as well to see the big picture. A lot of effort goes into using graphical methods (UML) to see what is happening. That's helps but does not resolve the problem I think. (It's astonishing that this is not the case in the Smalltalk culture).

One of the major problems seems to be that just one of the 'big' relations - implementation inheritance - can easily be used.

Inheritance has support by the tools in the system while aggregation/composition needs a lot of manual rewriring and cannot been seen easily detected afterwards. (Of course there are Inspectors and Explorers that help)

It would be nice to automatically support the concept of aggretation/composition: - an object has different roles. - there are browsers that show the aggreation / composition better. (within a compound object)

Taking the Morph class example:

A Morph may have a MorphExtension. (http://minnow.cc.gatech.edu/squeak/1935)

A MorphExtension may have otherProperties (an IdentityDictionary) (http://minnow.cc.gatech.edu/squeak/1935)

Many methods of Morph just rewire manually to MorphExtension and to the otherProperties dictionary.

If one could communicate this aggregation more clearly and support it with some kind of tools that would help considerably understanding the system.

I think most people on this list have problems understanding the Morphic framework although it is probably simple and elegant given the right design clues. But that does not show through.

To sum up: taking Squeak still as a research vehicle I would welcome Squeak developing in this direction. It is platform independent and works astonishingly smooth compared to the big problems other people are struggeling with. I agree with you in the sense of your 'the computer revolution hasn't happend yet'. I consider this step to be a stelp in the right direction.

Cheers

Hannes Hirzel

ALI Akan / ALI Swahili ICT department University of Zurich http://www.spw.unizh.ch

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

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/Aspect...

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

Thanks, Jim.

Have you tried to use AspectS for other tasks than debugging?

With AspectS you can change the behavior of the system not only at the level of classes, but also from the point of view of a subset of specific instances, either senders or receivers of a certain message, or both...

Best, -Robert

Jim Benson wrote:

Robert,

I've been using a previous version of your code for awhile now, and have found it invaluable. I've found it especially useful for UI debugging, as it seems the only sane way to try to figure out where the mouse clicks and motions are *really* going in the multi-layered morphic world.

Thanks,

Jim

...

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/Aspect S_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

Jim,

Thanks for the explanation. Making aspects project-specific is an interesting idea I never thought about before. Really nice!

Best, -Robert

As for the applications I have used

Jim Benson wrote:

Robert,

I've used it for simple tasks. Here's one way that I've used it as you've described:

I wrote a video-editing type of application which looked suspiciously like iMovie. I tried to emulate a typical desktop with dialog boxes, a tool bar and pull down menus.

Morphic has built in 'layering', that is, you can set the z-order of a morph by setting it's #morphicLayerNumber property. However, the PasteUpMorphs don't really honor that in the course of things when you add/remove morphs, so your system widgets tend to get written over and things are not pretty.

There are a couple of solutions to this. I could subclass PasteUpMorph into a "DesktopMorph" with all of it's attendant trappings. However, that type of implementation isn't very pretty as you have to reach further into the system code (and have a lot more system knowledge to do something which should be trivial) than necessary. I could be really careful about how I insert morphs onto my desktop, by substituting different addMorph type of calls for the normal ones (that's not in my nature ;-)

Or I could just let the machine do the work. Really, I only wanted to transform a couple of PasteUpMethods methods such as (conceptual code):

PasteUpMorph>>addMorph: aMorph self addMorphInLayer: aMorph.

to make them honor the morphic layering. Of course with your SAspect code this was easy. When I entered a video project, I would tell the project to install the appropriate aspect to make the PasteUpMorph morph (world) behave the way I wanted. When I left the project, I removed the aspect, which returned the image to stock behavior. This is all part of the MethodWrappers concept. This is all second nature to me, having patched many interrupt traps before.

In the Smalltalk world this is a very subtle nuance (like a 16 ton weight). I've redefined a methods behavior, not by overriding it or recompiling it as one would traditionally do, but by shaping it after it has been defined. This is also a different concept than having 'pluggable' behaviors, where one would store a method or block context for execution into an ivar and then substitute a different block of code into that ivar.

Of course, this is crucial to the modules code. I've been following the modules discussion here, but here's my fundamental concern: How do I end up not programming on quicksand? From what I understand so far, the modules solution is about keeping different chunks of code and data in a seperate space that you can 'swap' in. I can see how that works if the module is independent and does not change the 'base' image code. Where I get lost at is how all the modules interact when they fly back into the image, and start changing that base code, potentially over writing each others changes. If you don't have a stable base, and some protocol saying how you can attach changes onto that base, it turns to quicksand real quick.

I haven't looked very deeply into the weaving parts yet, though I think I have a good application for it in the area of autonomous characters. This is obviously the interesting area of your work. What type of applications have you been using it for?

Jim

...

Thanks, Jim.

Have you tried to use AspectS for other tasks than debugging?

With AspectS you can change the behavior of the system not only at the level of classes, but also from the point of view of a subset of specific instances, either senders or receivers of a certain message, or both...

Best, -Robert

Hannes,

...

I've updated a paper that describes AspectS in more detail:

http://www.prakinf.tu-ilmenau.de/~hirsch/Projects/Squeak/AspectS/Docs/Aspect S_20020222.pdf

I read the paper although not yet thoroughly. It is a bit terse for somebody not having followed the discussion on aspect oriented programming in the last years. However for many readers it will be just to the point.

The white paper interested folks should read is:

http://aspectj.org/documentation/papersAndSlides/ECOOP1997-AOP.pdf

which pretty much introduces what AOP is.

Jim

On Tuesday 26 February 2002 12:26 pm, Robert Hirschfeld wrote:

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/).

In the paper you thank: "Dan Ingalls for solving a puzzle that allowed the port of MethodWrappers to Squeak".

What puzzle was that? Just curious...