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.

Cheers,
   - Andreas