Hmm...I tried to describe it hastily (busy trying to get some other
stuff done)...apparently it wasn't very clear.

Simple example:

	- "Package A" overwrites the method #add: on OrderedCollection.
	- The method doesn't work properly and brings the system to its
knees (try it!)
	
What I have in mind solves this problem (providing that you are
developing within a package).  (note: people have previously suggested
that each package resolve the same symbol to a different object, but I
don't think this is the best way to go)

Let me try the description again:

The compiler, when compiling in "package A" would compile the #add:
method, but enter it into the method dictionary as #42add: (note: for
illustration I show the number, the first two bytes would actually be
binary encoded as 42...the high order bit of the first byte would be set
to clue the system that an index prefixes the real selector name...this
would prevent it from conflicting with other selectors).

Any sends of the message #add from methods compiled in "Package A" would
actually compile such that they send #42add: (oh, I chose 42 arbitrarily
as the Package index).  Then, message lookup in the VM would be modified
such that if a message #42add: is sent, but not found, it would retry
the lookup using the index pre-requisite packages to "Package A" one by
one, until each pre-req has been tried, or a matching method is found. 

Thus, if "Package A" imports "Package B", and Package B also overwrites
#add: on an existing class, the message lookup, after failing to find
#42add:, would then try #56add: (assuming the index of Package B is 56).
If that failed, and there were no further pre-requisites, it would
finally try #add:, and resolve the the #add: method implemented in base
Squeak.

Of course, the tools would have to be able to clearly convey this
information.  But, now, the user is free to overwrite
OrderedCollection>>add: for his/her experimentation, comfortable in the
knowledge that this change will not wreck the system.

Some of what I tried to explain in the previous email was relating to
the details of the implementation.

- Stephen  

> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org 
> [mailto:squeak-dev-admin at lists.squeakfoundation.org] On 
> Behalf Of Andreas Raab
> Sent: Wednesday, August 15, 2001 8:26 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: RE: [Modules] Name space semantics was: Re: Some of 
> my thoughts
> 
> 
> Stephen,
> 
> > I think this would be easy to implement and may be worth 
> > experimentation.
> 
> Ugh ... really?! It might be easy to implement but not 
> necessarily easy to comprehend - I at least couldn't even 
> follow your description... What is it that you're actually 
> trying to do?! Can you give a simple example?!
> 
> Cheers,
>   - Andreas
> 
> > -----Original Message-----
> > From: squeak-dev-admin at lists.squeakfoundation.org
> > [mailto:squeak-dev-admin at lists.squeakfoundation.org]On Behalf Of 
> > Stephen Pair
> > Sent: Wednesday, August 15, 2001 4:25 PM
> > To: squeak-dev at lists.squeakfoundation.org
> > Subject: RE: [Modules] Name space semantics was: Re: Some of
> > my thoughts
> >
> >
> > One issue that has been raised from time to time is the idea of 
> > selector name spaces.  The idea being that methods could be 
> added that 
> > are specific to some package, and can be easily installed and 
> > uninstalled.
> >
> > It would be nice to have this in the modules scheme I 
> think...but it 
> > would require enhancing message lookup.
> >
> > What if we were to prepend selectors with a couple of bytes 
> that were 
> > an index into an array (shared with the VM via the special 
> objects).  
> > The array would contain namespace objects, with some slot that 
> > contained a list of imported (prereq) name spaces.  For 
> message sends,
> > the compiler
> > would generate selectors with the index of the current namespace
> > prepended, the browsers would create method dictionary 
> entries having
> > selectors with these index bytes prepended.  Upon message 
> lookup, if a
> > matching method (for an namespace indexed selector) was not 
> found, we
> > would lookup the package based on the selector index, find the first
> > prereq and then attempt another lookup with the selector 
> modified for
> > the index of the prereq...this would be repeated until the list of
> > prereqs is exhausted, in which case the base selector
> > (without an index
> > prepended) is looked up.  The method cache should remain useful for
> > selectors with a namespace index prepended.
> >
> > I think this would be easy to implement and may be worth 
> > experimentation.
> >
> > - Stephen
> 
> 
>