Namespaces (was: Re: [ANN]A plan for 3.8/4.0... (insert drumroll here))

Avi Bryant avi at beta4.com
Thu Apr 1 22:53:41 UTC 2004


On Apr 1, 2004, at 2:39 PM, Andreas Raab wrote:

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

Yes, that was exactly my thought too.  Except:

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

I was thinking about going one simpler and having #'Squeak::Object' be 
the key in the Smalltalk dictionary too.  So importing a namespace #Foo 
into a class just means "try prefixing any symbols you can't resolve 
with 'Foo::' and see what happens then".  And of course a browser on 
namespace #Foo means "show me all the classes with name 'Foo::*', and 
strip off the prefix for my convenience".  They would still all show up 
with their full names in the normal browsers.

Ok, this is another of my PackageInfo-like games that goes for 
simplicity and compatibility over first-class-ness, but it would work, 
no?  And would have the short term advantage that code using this 
scheme would still file in just fine to older images, if they had the 
scanner hack.  Although your way is clearly cleaner and more consistent 
when extended to pools and nested namespaces.

At any rate, it seems like the first thing to do is to get the :: 
change made to the scanner so that we can easily try these ideas out.

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

Please do.

Avi




More information about the Squeak-dev mailing list