<br><br><div><span class="gmail_quote">On 11/29/06, <b class="gmail_sendername">Bert Freudenberg</b> <<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.
<br><br></blockquote></div><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.<br>