"Josh Flowers" <josh at i33.com> wrote:
>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.

Well, using the structures of Squeak as they exist (recall I said this ought to be a 1-week project, and we're already into the second day), class String either has or does not have a method for asHtml.  If it does, then it will understand it no matter who calls it.  If it does not, then it will get a dNU (doesNotUnderstand:) exception no matter who calls it.

I can only see two approaches to this.  The first is the static approach that I have already outlined for projects -- ie when you enter a project, all changes are asserted, and the system runs that way until you leave the project.

The second is a dynamic mechanism that would trap all accesses to any altered method, vectoring execution to alternate methods depending on the environment from which the message is being sent.  This mechanism would introduce a layer of simulation into the execution of any method that is added, removed, or altered in the base classes.

The general form would look like...
	someMessage
	    | pkg |
	    pkg := thisContext sender mClass environment.
	    pkg == Pkg1 ifTrue: [^ self pkg1someMessage].
	    pkg == Pkg2 ifTrue: [^ self pkg2someMessage].
	    ^ self originalsomeMessage].
....with dNU sends in various places for the cases of removals or new additions.  Obviously some browser support would be necessary to make sense of this.  Does anyone know of systems that actually work this way?

Does anyone know of a better solution to the problem (including "Just say no" ;-)?

If the general practice is to minimize changes to base classes, then notification of overlap plus VW's "last loaded wins" is probably adequate.

	- Dan