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