Maybe Robert Hirschfeld's stuff is interesting for you:

http://www.prakinf.tu-ilmenau.de/~hirsch/Projects/Squeak/PerspectiveS/

"PerspectiveS was inspired by the layers idea of the PIE system by Ira 
Goldstein and Daniel Bobrow. The main difference between the two 
systems is that while PIE simultaneously offers alternative designs to 
developers within their development environment, PerspectiveS allows 
design alternatives or variations to coexist concurrently at run-time. 
Such alternatives or variations are active depending on context 
information. "

Markus

Am Montag, 18.11.02 um 18:25 Uhr schrieb Brent Vukmer:

> Daniel --
>
> Weren't you working on a PIE implementation in Squeak?
>
> Daniel Joyce wrote:
>
>>
>> 	Take a look at Traits before reinventing the wheel. I think Traits 
>> are the best tradeoff between MI and SI w/o all the ugliness. Stepha 
>> Ducasse is working on it, IIRC. Very Very Cool Stuff!
>>
>>
>>> - Every selector bound to the abstract behavior which introduced it. 
>>> A behavior can only implement methods for selectors bound to it or
>>> its super behaviors (same as described before).
>>> - Environments representing versions/projects of Squeak containing
>>> new classes/versions and inheriting classes from zero or more other
>>> environments (same as described before).  But now an environment is
>>> also a namespace.  All local and inherited classes/vars of an
>>> environment, as well as their selectors, are visible to methods of
>>> classes in that environment.
>>>
>>> Environments form layers of Squeak.  Processes can run with respect
>>> to different environments on the same image.  Classes of an
>>> environment can be downloaded together or individually.  Class
>>> prerequisites can be downloaded with the class automatically, or on
>>> demand during runtime.
>>>
>> 	
>> 	Sounds like PIE, I posted a message with exactly these ideas a few 
>> weeks ago. Also, it gives us other goodies too, like easy 
>> type-inferencing.
>>
>>> The key to this design, and any package design, I think, is that
>>> class extensions are first class objects (I make them new super
>>> behaviors). When they are not first class objects they act like
>>> changes to a class. Changes is a lot harder to manage and mix than
>>> separate objects, so you want to keep them to a minimum.  In this
>>> design, only true behavior changes need to be managed as changes. 
>>> They are managed as versions in environments that override versions
>>> in inherited environments.
>>>
>>>
>> 	Bingo!
>> 	Look for messages on Traits and PIE, and that old message from me...
>>
>>
>>>
>>
>
>