<br><br><div><span class="gmail_quote">On 12/4/06, <b class="gmail_sendername">J J</b> <<a href="mailto:azreal1977@hotmail.com">azreal1977@hotmail.com</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;">
>From: Bert Freudenberg <<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>><br>>Reply-To: The general-purpose Squeak developers<br>>list<<a href="mailto:squeak-dev@lists.squeakfoundation.org">
squeak-dev@lists.squeakfoundation.org</a>><br>>To: The general-purpose Squeak developers<br>>list<<a href="mailto:squeak-dev@lists.squeakfoundation.org">squeak-dev@lists.squeakfoundation.org</a>><br>>Subject: Re: Squeak and Namespaces
<br>>Date: Sat, 2 Dec 2006 23:06:02 +0100 (MET)<br>><br>>On Dec 2, 2006, at 22:32 , J J wrote:<br>><br>>>As far as what is the best solution for namespaces, here is my personal<br>>>pick:<br>>>
<br>>><a href="http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-">http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-</a><br>>>November/111762.html<br>>><br>>>No new syntax (I think), and it gives a lot more then just prefixes.
<br>><br>>This sounds like it would be realizable with Squeak's #environment hooks.<br>>Are you up to implementing a prototype so we could try it?<br>><br>>- Bert -<br><br>Unfortunately no. I have no time at all right now (new job, long hours,
<br>long train ride, new child). But it seems like that is a problem we all<br>have.<br><br>I know on mozilla they do a bounty system to get work done. I know it has<br>been suggested before, but who all would be willing to put up at least $20
<br>for something that needs to be done in smalltalk? And the more jump in, the<br>less it would cost per person. $10 from 100 people might get some work done<br>and might be easier to get then $20 from 50 people.</blockquote>
<div><br>...or you could save your money and wait :-). I *need* Namespaces for security in my DPON project. Eventually I'll have some code to show; I worked on it a bit in the weekend, but got pulled away by the rest of life :-(.
<br><br>My design is roughly as follows. I'm still working on it, so it may change: <br><br>- "Namespace" is a class. That's always a good starting point :-). It subclasses Dictionary and can be thought of as replacing the #Smalltalk SystemDictionary.
<br><br>- Each "Namespace" has a Collection of imports, which are other Namespaces or maybe wildcards(?), and a pointer to the root namespace.<br><br>So when a shared variable such as a class is referred to from code, the compiler searches that classes' namespace, then the root namespace, then the import list. I guess a full search must be done each time and the user notified if there are multiple matches for that shared variable name.
<br><br>This allows nested namespaces:<br><br>root := Namespace new.<br>root at: #Squeak put: (squeakns := Namespace new name: #Squeak).<br>squeakns at: #Collections put: (collectionsns := Namespace new name: #Collections).
<br>collectionsns at: #OrderedCollection put: (get the #OrderedCollection class here).<br><br>so then:<br><br>myOrderedCollection := Squeak.Collections.OrderedCollection new.<br><br>I prefer the dotted notation; this is purely a subjective preference.
<br><br>Alternatively, you could do:<br><br>self class namespace import: (Squeak.Collections). "Which you'd probably do with dev tools"<br>o := OrderedCollection new.<br><br></div></div>I still can't decide whether I want to separate the import mechanism into a separate class, so that every class has a private list of namespace imports. So far I've come to the conclusion that this would be tightly coupled, 1 to 1 with Namespace so they may as well be the same class.
<br><br>This allows security: There can be multiple root namespaces each with a different set of accessable classes and shared variables. It is also allows imports to other namespaces, so that an individual namespace can be granted access to a particular class or namespace which it otherwise wouldn't have access to. If there are any obvious security flaws here, please point them out to me :-).
<br><br>This would require a bit of re-thinking about how the development tools are used. I'd probably make a "Namespace browser", and you'd have to open workspaces, browsers, etc from that so that the workspaces etc have access to classes and shared variables from that Namespace.
<br><br>Finally, classes will no longer have access to the #Smalltalk SystemDictionary, for obvious security reasons. There are a few notes in the wiki at <a href="http://www.squeaksource.com/SecureSqueak.html">http://www.squeaksource.com/SecureSqueak.html
</a>. I'll put the code there when it actually does something useful.<br><br>Michael.