Michael’s description is something like what GemStone/Smalltalk provides—each login is assigned an array of SymbolDictionary instances (a SymbolList), and compiling is in the context of a SymbolList. You can have multiple globals visible with the same name, but the first one found is used. Different code can be compiled with different instances of SymbolList, and multiple instances of SymbolList can reference the same SymbolDictionary. Security can be addressed by giving a user a SymbolList that does not reference things that should be hidden.

James Foster

-----Original Message-----
From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Michael van der Gulik
Sent: Wednesday, November 29, 2006 6:32 PM
To: The general-purpose Squeak developers list
Subject: Re: Squeak and Namespaces

On 11/29/06, Bert Freudenberg <bert@freudenbergs.de> wrote:

Actually, that is the beauty of the proposal. Colons are already
allowed unquoted in a symbol. #My::Class is valid right now. In this
proposal, the compiler knows *nothing* about namespaces. It just
permits a colon in a global identifier. It's the only syntax change.

I don't know what to think of the syntax; it smells a bit like C++. I prefer dotted namespaces, but that's quite subjective and not really a killer issue.

I disagree with the implementation. I personally think that the Smalltalk SystemDictionary should be split up into multiple, nested Namespaces (which are subclasses of Dictionary). These would have some mechanism, such as import lists, to glue them together. At this stage, I don't have a well-thought out alternative proposal.

The proposed implementation also doesn't solve one of the problems that Namespaces could solve: security. I'm writing a distributed environment that provides a sandbox for remote code; the remote code must be denied access to the SystemDictionary for securities' sake. Instead, remotely loaded code should only have access to particular Classes and "global variables" in the Namespaces that the remote code has access to. The namespace of a particular class could be stored in the class's "environment" variable.

I suppose it doesn't really matter; if I use the same notation and semantics for resolving classes and global variables, then code would continue to compile under both this proposal and an alternate namespacing implementation that I'll be writing.

Michael.