What about something similar to Catagories in Objective-C?  Packages can add/change
messages to base classes, but not variables, and those messages are invisible to other
packages.  

If HTMLPackage adds an asHtml method to String, a subclass (or a new Catagory) of String
is created, and put in the HTMLPackage dictionary.  When an object within the HTMLPackage
calls asHtml on a String the message is understood, but when the string object is
referenced from another package, the asHtml message would no longer be valid.

Usual new user disclaimer.

>"Pennell, David" <dpennell at quallaby.com> wrote... 
>>A related issue is supporting "base class changes".  I know its  
>>controversial in some quarters, but it certainly is common for  
>>packages to add a method here and there to Object,UndefinedObject, 
>>String, etc.  This also has implications in the browsers. 
>
>This is a tough one.  I can see how to handle it for internal access.  Our 
>plan for this is to tap into the "isolated projects" mechanism that I 
>proposed way back and Ted implemented last spring.  The idea is that 
>changes to system classes get asserted and retracted when you enter/leave a 
>project.  This is one of the things that works nicely when packages are 
>identified with projects. 
>
>The problem comes when several packages make simultaneous changes to the 
>base system.  In this case it becomes overly complex to manage assertion 
>and retraction.  You can deal with it stylistically (don't change the base 
>classes (or almost never)) and/or administratively (declare such changes 
>and warn of any conflicts). 
>
>If I had to call this right now, I would prohibit packages from making any 
>changes outside their own scope but I would allow projects to have attached 
>changes that would be asserted and retracted according to the current 
>isolated projects mechanism. 
>
>I could imagine a hybrid form of use evolving, where someone writes a big 
>package like T-gen as a project with changes to the base system, and then 
>clients access it through a protocol that asserts those changes for the 
>duration of that access, but this just increases the use of something I don't really like. 
>
>Can anyone suggest a better approach to this? 
>
>    - Dan 
>
>