Quoting Bert Freudenberg <bert at impara.de>:

> Am 10.04.2004 um 21:35 schrieb Lex Spoon:
> > The tools-only approach to namespace imports is actually worse than
> > this.  While I must set up my C indentation to *edit* other people's
> > code, we are talking about setting up a LookupContext before I can even
> > *browse* other people's code.  That seems like a major pain and a big
> > step backwards over the simplicity of browsing Smalltalk right now.
> 
> What if we store the lookup context with the file-out? That way, 
> another user would see exactly what the author intended.
> 
> Whenever we file out something, be it a single method or a package 
> containing hundreds of classes, we could just store the LookupContext 
> as a prefix. This would define the "default view" when I later file in 
> this piece of code.

This makes a lot of sense to me. 

Really, namespaces should be attached to packages. (I can see Andreas and Goran
both grimacing here - for different reasons - but just hear me out, ok?) That's
not to say that each package should have it's *own* namespace, but just *a*
namespace, a definition of the lookup context in which its code is meant to be
compiled. Packages would be able to include namespaces, but namespaces would
know nothing about packages.

The fact that not all code is part of a package yet isn't really a problem - we
just create a package called Squeak that contains all the spaghetti we're still
untangling. Heck, that beast is already on SqueakSource.

Another thing I've noticed about the Namespace discussion to date is that it
seems to focus entirely on classes. Remember that name resolution also has to
take into account class variables, pools and globals. So treating a namespace
as
a "flat" list of bindings doesn't quite work. 

Just for kicks I went ahead and implemented a Namespace class along the lines I
mentioned in my last post. Unfortunately I can't post the code until Thursday
or Friday, when I'm supposed to get an internet connection installed. However,
below are some snippets to illustrate how namespaces could be used:

"Ask a class for its namespace, then resolve variable names,
more or less the way the compiler would do."
ns := aClass namespace.
associationOne := ns bindingOf: #Delay.
associationTwo := ns bindingOf: #Tweak::Delay.

"Build a custom namespace"
outer := Dictionary new.
outer
    at: #One put: 1;
    at: #Two put: 2;
    at: #Three put: 3.
inner := Dictionary new.
inner
    at: #Two put: 'two';
    at: #Four put: 44.
ns 
    addScope: outer;
    addScope: inner.

"Do some lookups with it."
(ns bindingOf: #One) value     "answers 1"
(ns bindingOf: #Two) value     "answers 'two'"

"Make the namespace available for reference 
via fully qualified variable names."
ns exportAs: #Foo.
Foo::Two              "resolves to 'two'"

"Build a namespace for doing advanced graphics, assuming
that the requisite exports have already been done."
ns := Namespace new.
ns 
    import: #Kernel;
    import: #Collections;
    import: #Croquet;
    import: #Tweak.
(Package named: 'MyVirtualWorld') namespace: ns.



Ok, that last bit about assigning a namespace to a package obviously isn't
implemented yet, but the rest is. The nice thing about this scheme is that the
source code doesn't shift under your feet as you load different packages with
different namespaces, but the neither is it cluttered with fully qualified
names. Finally, its simple to implement, simple to understand, and flexible
enough to handle the really bizarre cases that tools like Monticello,
SqueakSource and SqueakMap are likely to encounter. 

I'll post the prototype as soon as I can.

Colin