Squeak and Namespaces

Göran Krampe goran at krampe.se
Fri Dec 1 11:54:29 UTC 2006


Hi!

> On Dec 1, 2006, at 11:16 , Andreas Raab wrote:
>
>> Bert Freudenberg wrote:
> Anyway - maybe you could explain your Tweak namespace semantics a bit
> more? It seems equally simple as Göran's but maybe could attract more
> followers? I'll copy the class comment below ...
>
> - Bert -
>
> [CNamespace class comment 'ar 3/27/2004 17:12']
>
> WARNING: THIS IS UNFINISHED AS OF YET! But here's how it's supposed
> to work anyways:
>
> Essentially, we don't want to screw with all of the existing tools in
> Squeak, so we just define that all classes are in the global
> namespace "Smalltalk" but that the names of the classes are really
> fully qualified ones. So, for example, the instance variable name
> 'name' of class Bar in namespace Foo will contain #'Foo::Bar' and we
> merely fix the lookup so that the namespace contains an entry under
> #Bar which is found by the compiler. This allows us to leave all of
> tools alone working with the name of #Foo::Bar if they aren't
> namespace-aware and have the tools which *are* namespace aware to use
> #localName or #fullName as they desire.
>
> This scheme has various advantages: a) You can reflect about all
> classes in the system by enumerating through Smalltalk (useful for
> system-wide tools). b) When we print an object (or inspect a class or
> similar) we will see it's full name which is good as it avoids
> confusion. c) If we want to "import" some class it will know where it
> was defined so we can track that dependency accordingly. Etc. This
> seems *hugely* advantageous to approaches which try to keep the
> "local name" of the class and do all sorts of guessing about "who
> this guy is" (say, Environment>>scopeFor:from:envtAndPathIfFound:) -
> after all if a class doesn't know where it is defined, who the hell
> *would* know?
>
> So the basic approach here is: Classes know who they are and where
> they are defined, and we can ask them for a local name which will be
> a "shorthand notation" in their namespace.

So far this seems IDENTICAL to my solution, modulo any misunderstanding on
my part.

> The stuff that really doesn't work right now is to fix the tools to
> the point that they can deal with namespaces AT ALL. There are so
> many freaking places in the system that are hardwired it's almost
> impossible to fix them all at once. For example, there's an
> interesting issue with respect to defining classes - those class
> definitions *have* to be executed by the environment that defines the
> class but unless we want to change the class definition message
> (which would screw up even more tools) you can't really guess which
> name is being used. Argh... anyways if you want to see what I'm
> talking about try to define something like:
>
> Squeak::Object subclass: #Object
> 	instanceVariableNames: ''
> 	classVariableNames: ''
> 	poolDictionaries: ''
> 	category: 'Tweak-Kernel'
>
> inside the Tweak namespace. You'll see what I'm talking about...

This part I need to test to understand the problem. :) I don't have a
Squeak handy right now but if the intention is to create a class
Tweak::Object, then why not name it that?

regards, Göran




More information about the Squeak-dev mailing list