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