Squeak and Namespaces

Bert Freudenberg bert at freudenbergs.de
Fri Dec 1 10:44:02 UTC 2006


On Dec 1, 2006, at 11:16 , Andreas Raab wrote:

> Bert Freudenberg wrote:
>> Is there really a scheme of namespaces that would not support  
>> fully qualified names? Given that Göran's proposal basically  
>> suggests one way of expressing FQNs, shouldn't it be easily  
>> supported by any namespace implementation?
>
> There probably isn't a scheme that doesn't require some sort of  
> qualified names. However, what the exact semantics of those  
> qualified names is, is an entirely different question. For example,  
> there is already a significant difference between Goran's proposal  
> and what is currently in Tweak. Goran's proposal (as far as I  
> understand it) is effectively saying that the result of evaluating  
> Foo::Bar is equivalent to "Smalltalk at: #'Foo::Bar'" whereas Tweak  
> treats it as "(Smalltalk at: #Foo) at: #Bar" (with special  
> exceptions for classes to appear in Smalltalk to keep the tools  
> happy). The difference? Well, how about something like
>
>   TextConstants::CR
>
> which (in Tweak) works just the way I'd expect whereas in Goran's  
> proposal I have no idea what the intended result is.
>
> And decisions about semantics like here *do* matter. For example,  
> if one agrees that the Tweak way is The Right Thing To Do, you'll  
> immediately notice that you get into deep trouble with Goran's  
> "source code beautifier" since you *can't* just write the  
> abbreviated form (CR) and writing the "full form" would imply that  
> there is some other scope that includes CR (which there may not)  
> and determining whether a name needs to be qualified or not  
> suddenly needs to do a deep search of all possible pools etc. etc.  
> etc.
>
> So the semantics of the FQNs are quite significant for their usage  
> a little bit down the road. And while it may be that Goran's  
> proposed semantics is just the right one it is equally likely that  
> it's just the wrong one.  And we haven't even started talking about  
> static (compile time) vs dynamic (runtime) lookup of names yet. In  
> my understanding you can only define the semantics of FQNs properly  
> if you know what you want to do with them.

Agreed, although the problem in your example is just that there are  
two competing uses of the :: qualifier. But in the case that you only  
have code with one semantic and syntax for FQNs, it should not be too  
hard to migrate to an extended semantic keeping the same syntax. It  
is hard or impossible to change the semantics completely, that is true.

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.

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




More information about the Squeak-dev mailing list