On 12/4/06, J J <azreal1977 at hotmail.com> wrote:
>
> >From: Bert Freudenberg <bert at freudenbergs.de>
> >Reply-To: The general-purpose Squeak developers
> >list<squeak-dev at lists.squeakfoundation.org>
> >To: The general-purpose Squeak developers
> >list<squeak-dev at lists.squeakfoundation.org>
> >Subject: Re: Squeak and Namespaces
> >Date: Sat, 2 Dec 2006 23:06:02 +0100 (MET)
> >
> >On Dec 2, 2006, at 22:32 , J J wrote:
> >
> >>As far as what is the best solution for namespaces, here is my  personal
> >>pick:
> >>
> >>http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-
> >>November/111762.html
> >>
> >>No new syntax (I think), and it gives a lot more then just prefixes.
> >
> >This sounds like it would be realizable with Squeak's
> #environment  hooks.
> >Are you up to implementing a prototype so we could try it?
> >
> >- Bert -
>
> Unfortunately no.  I have no time at all right now (new job, long hours,
> long train ride, new child).  But it seems like that is a problem we all
> have.
>
> I know on mozilla they do a bounty system to get work done.  I know it has
> been suggested before, but who all would be willing to put up at least $20
> for something that needs to be done in smalltalk?  And the more jump in,
> the
> less it would cost per person.  $10 from 100 people might get some work
> done
> and might be easier to get then $20 from 50 people.


...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
:-(.

My design is roughly as follows. I'm still working on it, so it may change:

- "Namespace" is a class. That's always a good starting point :-). It
subclasses Dictionary and can be thought of as replacing the #Smalltalk
SystemDictionary.

- Each "Namespace" has a Collection of imports, which are other Namespaces
or maybe wildcards(?), and a pointer to the root namespace.

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.

This allows nested namespaces:

root := Namespace new.
root at: #Squeak put: (squeakns := Namespace new name: #Squeak).
squeakns at: #Collections put: (collectionsns := Namespace new name:
#Collections).
collectionsns at: #OrderedCollection put: (get the #OrderedCollection class
here).

so then:

myOrderedCollection := Squeak.Collections.OrderedCollection new.

I prefer the dotted notation; this is purely a subjective preference.

Alternatively, you could do:

self class namespace import: (Squeak.Collections). "Which you'd probably do
with dev tools"
o := OrderedCollection new.

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.

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 :-).

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.

Finally, classes will no longer have access to the #Smalltalk
SystemDictionary, for obvious security reasons. There are a few notes in the
wiki at http://www.squeaksource.com/SecureSqueak.html. I'll put the code
there when it actually does something useful.

Michael.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20061204/443f1b89/attachment.htm