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

> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org 
> [mailto:squeak-dev-admin at lists.squeakfoundation.org] On 
> Behalf Of Dan Ingalls
> Sent: Wednesday, August 15, 2001 5:01 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Re: [Modules] Name space semantics was: Re: Some of 
> my thoughts
> 
> 
> Henrik Gedenryd <Henrik.Gedenryd at lucs.lu.se> wrote...
> 
> >Smalltalk usually early-binds all variable references, incl. 
> globals. 
> >In the above solution (export globals via methods in Environment 
> >subclasses), implicit/inherited references are early-bound 
> (at compile 
> >time), while qualified references are late-bound (at runtime).
> >
> >This results in a semantic ambiguity which I believe we need 
> to avoid. 
> >I think qualified refs should simply also be early-bound.
> >
> >Thus, the compiler sends these messages at compile time, after e.g. 
> >simply looking for Capitalized unary message names, and then 
> stores the 
> >resulting literal in the CompiledMethod, as with globals today. This 
> >preserves the current, unified semantics of always early-binding 
> >variable references.
> 
> Hi, Henrik -
> 
> Thanks for your careful read of the Environments scheme.
> 
> There is a reason why I left foreign references interpreted.  
> It wasn't for the lateness benefit (ie perhaps changing the 
> binding (but see below)), but so that we could *invalidate* 
> the binding by swapping a module out.  This is one of the 
> things that makes the Environments scheme sort of unusual.
> 
> The idea (and this all actually ran at one time) is that you 
> can swap an entire Environment out as an image segment.  
> Then, since foreign references are of the form
> 	Envt Thing
> an attempt to refer to Thing will cause a message-send to the 
> image segment root stub, giving Squeak a chance to swap in 
> that segment and resume the message send.
> 
> If you do the binding early, then you have a literal pointing 
> directly at the association for Thing, and the VM will crank 
> its way into invalid pointers if the segment is out.  
> Actually, this won't happen.  Instead the segment creation 
> machinery will fail to find a swappable region due to the 
> literal pointers into it.  This can be hacked by making every 
> dictionary entry a root for the segment, but you still have 
> the problem that the VM will try to crank its way through 
> invalid stuff on the literal reference.  This can be further 
> hacked by making every internal referent a root, but I felt 
> it was in conflict with some basic principle.  When I stepped 
> back from all this I said "Ah, references to the internals of 
> an environment can only be made by sending a message," and 
> that's how it works.
> 
> By the way, it occurred to me that the late binding property 
> *would* be nice for the following situation:  I have one 
> package called Files, and another called NewFilesExperiment.  
> I should be able to just type (after saving ;-)
> 	Files := NewFilesExperiment
> and suddenly everything in the system should be running with 
> the new bindings.  I gather this is one of the things people 
> like about packages.
> 
> I did think it was pretty cool to get both name spaces and 
> packages in only a few pages of code, but a lot of the work 
> of browser support, package dependence, etc., remains incomplete.
> 
> 	- Dan
> -- 
> 
>