Hi andreas

Do you use the Environment class?
I did not really like the idea to use inheritance as nested namespace.

In fact in classBox that alex will release soon we have the same design
(from what I can say). I think that even better you do not have to have 
Foo::MyClass in the
class description (alex do am I right?)

I agree for the tools issue. I think that also one big mistake of VW 
namespace is that let
a class import a namespace this is really bad.
Now with classbox we unify classVar Pool as classBox variables.

I would like to get the code too

Stef


On 2 avr. 04, at 00:39, Andreas Raab wrote:

> 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
>
>