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 at lists.squeakfoundation.org
[mailto:squeak-dev-bounces at 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 at 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20061129/e88ed61a/attachment.htm