<html>
<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 10 (filtered)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:blue;
text-decoration:underline;}
span.EmailStyle18
{font-family:Arial;
color:navy;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
{page:Section1;}
-->
</style>
</head>
<body lang=EN-US link=blue vlink=blue>
<div class=Section1>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>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.</span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'> </span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>James Foster</span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'> </span></font></p>
<p class=MsoNormal style='margin-left:.5in'><font size=2 face=Tahoma><span
style='font-size:10.0pt;font-family:Tahoma'>-----Original Message-----<br>
<b><span style='font-weight:bold'>From:</span></b>
squeak-dev-bounces@lists.squeakfoundation.org
[mailto:squeak-dev-bounces@lists.squeakfoundation.org] <b><span
style='font-weight:bold'>On Behalf Of </span></b>Michael van der Gulik<br>
<b><span style='font-weight:bold'>Sent:</span></b> Wednesday, November 29, 2006
6:32 PM<br>
<b><span style='font-weight:bold'>To:</span></b> The general-purpose Squeak
developers list<br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: Squeak and Namespaces</span></font></p>
<p class=MsoNormal style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'> </span></font></p>
<p class=MsoNormal style='margin-right:0in;margin-bottom:12.0pt;margin-left:
.5in'><font size=3 face="Times New Roman"><span style='font-size:12.0pt'> </span></font></p>
<div>
<p class=MsoNormal style='margin-left:.5in'><span class=gmailquote><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>On 11/29/06, <b><span
style='font-weight:bold'>Bert Freudenberg</span></b> <<a
href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>> wrote:</span></font></span></p>
<p class=MsoNormal style='margin-right:0in;margin-bottom:12.0pt;margin-left:
.5in'><font size=3 face="Times New Roman"><span style='font-size:12.0pt'>Actually,
that is the beauty of the proposal. Colons are already<br>
allowed unquoted in a symbol. #My::Class is valid right now. In this<br>
proposal, the compiler knows *nothing* about namespaces. It just<br>
permits a colon in a global identifier. It's the only syntax change. </span></font></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'><br>
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.<br>
<br>
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. <br>
<br>
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. <br>
<br>
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. <br>
<br>
Michael.</span></font></p>
</div>
</body>
</html>