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