Hi!
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.
I actually do it "both" ways right now. :)
The code on SM does it the way you say "(Smalltalk> at: #Foo) at: #Bar" as can be seen on (#scopeVariable):
http://swiki.krampe.se/gohu/35.version?id=11
...and the code I wrote last night to get the minimal core working:
http://swiki.krampe.se/gohu/35
...does it like "Smalltalk at: #'Foo::Bar'" because then there is no Namespace instance hanging at "Smalltalk at: #Foo".
Since this is compile time stuff (no speed requirement) I prefer the two step lookup for obvious OO reasons. If we want it to work that way all the time (even with the minimal core) then we need to make the core larger (add Namespace class, make sure they get created and hooked into Smalltalk upon class creation etc - I haven't looked through how much more changes that would be).
As a sidenote I have not considered using this for anything else than globals.
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.
If we would like to use it for non globals (such as pools, which I am not sure I would like :)) then sure, it is not clear. I never intended to. One way might be to just notice that, hey, this is not a global and just never abbreviate it.
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.
My solution was primarily compile time focused, but since we would have Namespace instances hanging in Smalltalk (that acts like Dictionaries) it also enables "normal" runtime lookup like:
Foo at: #Bar
Cheers,
- Andreas
Just giving you my thoughts/feedback, ok? :)
regards, Göran