>
> What I'm proposing is meant for 4.0, not 3.4.  These changes require
> image format changes.  I will create of new version of VI4 called VI5
> so we can start experimenting with these changes.  I am presenting
> this design now in case we want to adapt our current approach to
> packaging in light of possible future adoption of this design, or
> something similar.
>
> I think 3.3 failed because the design was poor, the implementation
> was incomplete, and the author quit supporting it.  The design lacked
> selector namespaces, conflict resolution, multiple versions,
> first-class extensions (more on this later), and automatic detection
> of
> prerequisites (particularly through message sends).
>
> I know what I'm proposing includes some radical changes, but I think
> these changes are beneficial on their own, plus they make packaging
> easier, so I hope people could grok it.
>
> Here is a synopsis of what I'm proposing:
>
> - Multiple inheritance of behavior only (same as I described before
> in "Class Dependencies").

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

> Cheers,
> Anthony

	We're saying the same thing here guys...