Hi,
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of J J Sent: Wednesday, November 29, 2006 10:21 PM To: squeak-dev@lists.squeakfoundation.org Subject: RE: Squeak and Namespaces
From: "James Foster" james@foster.net Reply-To: james@foster.net, The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: "'Michael van der Gulik'" mikevdg@gmail.com CC: 'The general-purpose Squeak developers list'squeak-dev@lists.squeakfoundation.org Subject: RE: Squeak and Namespaces Date: Wed, 29 Nov 2006 21:58:49 -0800
Importantly, there is no change in the language syntax. The "magic"
happens
during method compilation where one of the arguments to the compiler is
the
SymbolList instance that is to be searched for any needed global references. Different methods can be compiled with reference to different SymbolList instances, and still call each other. This allows for private classes, class replacement, etc. It has served reasonably well for a couple decades.
This is all very interesting. So I guess the given user has to be explicitly set up to use any namespace they get?
By default, the existing tools that create a new user give the new user a specified subset of the existing SymbolDictionary instances.
And if one is added you rebuild all the places the user is being implicit since he may now be talking about a totally different class even though his code didn't change?
If a new SymbolDictionary is added to the image then it is not visible to a user till it is added to that user's SymbolList. Adding it to a user's SymbolList only impacts methods that are compiled later. Compiled code remains bound to the globals (Association) referenced when the methods were compiled. If you wanted to change the bindings, you would need to recompile the methods.
James