Cees de Groot wrote:
> On Fri, 11 Feb 2005 10:33:07 -0500, Lex Spoon <lex at cc.gatech.edu> wrote:
>
> > I would say that this *is* a namespace approach.  Objects will
> > presumably want to refer to items in other partitions than their own.
> > What do you do?  Import a local name for it?  Specify it explicitly
> > ("item foo of partition bar")?

No, don't import, don't allow absolute names anywhere in the system.

The only namespace system that I know of that does it 'right' is the one used 
in Forth.

When a forth program is loaded that module does not reference the namespaces 
it needs, rather the namespaces are provided prior to loading. These 
namespaces are not referenced from the module, the source simply references 
short global names it needs.
Also the visible namespaces and the target namespace being compiled into are 
rigorously separated.

This setup makes it possible to load a module binding to the *contents* of a 
standard namespace like Smalltalk or a less standard one like 
MySandboxedSmalltalk. Indeed you could do both loads into a single image 
provided the target namespace is different for both loads.

The power offered to you here is that you can parameterize your source, you 
can load it multiple times with different semantics if you provide different 
bindings for the globals referenced in the source.

This setup smacks of capabilities, so if it is augmented with read-only and 
read-write references to a namespace you could make a capabilities based 
system out of it where the loader is providing a binding for _named_ 
capabilities while preventing malicious injection of names into the provided 
namespace references.


In forth namespaces are just SystemDictionaries. There is a stack of namespace 
references called SEARCH-ORDER that the module under load is free to 
manipulate at load time (provided is has references to the namespaces it 
wants to stick in the search order). Name lookup works very simply by walking 
all the namespaces on the search-order until it finds a hit. No ambiguities 
to resolve (just like in St method lookup).

Currently I think you are doing something wrong
--if you introduce a distinguished or 'root' namespace
--if the module can import namespaces
--if namespaces can import namespaces
--if you introduce arbitrary rules for name disambiguation
--if a name can become ambiguous by loading an unrelated module
--if an object can be referenced by only one name/
  if a namespace item has a distinguished parent


Go shopping instead of reinventing this wheel :-) Forth is a 'must visit' in 
this respect. I think its namespace model is general enough to emulate all 
the other St namespace suggestions I have seen so far. Forth namespaces are 
much more like object soup than like the hierarchies we see in Java and VW.


So: use namespaces to compose a binding environment to use during load rather 
than allowing the module being loaded to dictate this environment statically.

R
-