Hi Avi,

> Thoughts?

Lots of them. I have an "almost working" implementation of Namespaces in
Tweak which is pretty close to what you describe. I chose to use Foo::Bar
for scoping the variables merely because colons are treated specially by the
scanner already (both for assignment as well as for keywords) and it seemed
(and was) simplest to basically copy the code for assignment here ;-)

This is then hooked into #bindingOf: so what you can say for example is
GZipConstants::GZipMagic to retrieve the GZipMagic constant from
GZipConstants. Works perfectly well and is really straightforward to
implement and to use.

The real problematic issue is what to do about namespace management. In
other words, the place where all of the prior approaches broke down was that
"just having namespaces" isn't even remotely enough - all of your tools have
to be namespace aware and that is really a daunting task.

So I decided to address this issue differently - rather than hacking all of
the current stuff, a class defined inside a namespace carries its full name,
e.g., the iVar "name" of class Foo::Bar actually says #'Foo::Bar'. This
scheme is in my understanding hugely advantageous to any of the other
previously tried approaches as it basically says that

a) The class knows how and where it is defined so there is no need to do
"backwards guessing" (say ... eeeek! who added these *ugly* horizontal
scrollbars to the browser lists in 3.7??? ... anyway I meant to say
Environment>>scopeFor:from:envtAndPathIfFound:) since if a class doesn't
know how and where it is defined, who *would* know?

b) Non-namespace aware tools can continue to function properly (all of the
classes are under their fully qualified names present in the Smalltalk
namespace)

c) Namespaces "merely" provide a convenience shortcut via the "short name"
of the class.

This actually all works, except that there are still a number of places
which make a number of problematic assumptions about class definitions. The
biggest problem is actually treating classes as a doIt - it prevents in
various places that you can specify the appropriate namespace, for example
by doing something like (in a browser in another namespace):

Squeak::Object subclass: #Object
    instanceVariableNames: ''
    classVariableNames: ''
    poolDictionaries: ''
    category: 'Tweak-Test'

This makes ClassBuilder barf about "Object inheriting from Object"
although -by the context provided through the namespace-aware browser- it
should be clear that I am in an entirely different namespace where "Object"
isn't "Squeak::Object" ("Squeak" is the name of the "root namespace", aka
Smalltalk). So one of the things that still need to be fixed is that the
namespace is part of the "compiler attributation" rather than being used
(such as in ClassBuilder) via the superclass' environment.

BTW, if you're interested in this I can send you a link to the relevant
code.

Cheers,
  - Andreas