Hi Lex!

"Lex Spoon" <lex at cc.gatech.edu> wrote:
> goran.krampe at bluefish.se wrote:
> > Not wanting to sound like a parrot :) but again - why would we end up
> > having to read fully qualified names? You may not be describing my
> > proposal anymore (not sure) but if you *are* then the only reason for a
> > fully qualified name to appear in the Tweak code would be if an object
> > was referenced in a Tweak method that:
> 
> Yes, in the baseline "quick" proposal, with no additions, people will
> frequently end up viewing fully qualified names. 

I still disagree. :)

> Here's the scenario.  Andreas writes a humongous blop of code called
> Tweak which has its own namespace and which has a lot of collisions with
> the rest of Squeak.  Andreas files out his code and mails it to Alice. 
> Alice loads the code and tries to browse it.
> 
> That's it.  Note that Alice has browsers with a different lookup context
> than Andreas.  Quite possibly Alice is using the default context that
> Squeak ships with, because she is trusting her tools to have good
> default settings.  Whenever Alice views Tweak code, all the Tweak
> references will have fully qualified names.

No, no, and again no. :)

When she views Tweak code NOT ONE reference to names defined in the
local Tweak:: namespace will be rendered fully qualified. Not a single
one.

If she views code in a different namespace that references classes IN
Tweak then SOME of those references will be rendered fully qualified,
namely the ones that ALSO exists in other namespaces in her image.

Ok, let me show two methods, one from our imaginery blop of code - the
Tweak::Button>>click method:

click
	(currentEvent type == Button clickType)
		ifTrue: [Window close]

...well, that was silly code. :) Imagination is low. Anyway, here you
can see that neither Tweak::Button nor Tweak::Window is rendered fully
qualified *because they are defined in the local namespace*.

Ok, next method, this time from the Whack framwork built on top of Tweak
that Alice has:

whack
	myButton := Tweak::Button new.
	myWindow := Window new

...here we see that Tweak::Button is fully qualified because there is
also a Tools::Button class in the image. Tweak::Window is still not
qualified because there is no other Window class in Alice's image (he,
whaddayaknow).

So in fact - there will be VERY FEW fully qualified names. And if some
of the names that actuall do conflict have been marked as "shy" then
those would perhaps not be fully qualified either (not sure, but it is a
plausible thing).

> Now, there is an argument that this may be good.  After all, it makes it
> very clear what the individual variables are referring to.  However, it
> also makes the overall algorithm much harder to read.  Further, the code
> is definitely in a different form than the maintainer likes to view and
> edit the code.  Further yet, no matter what the default rendering is, a
> confused user can always tell their tool to use full qualification if
> they desire it.
> 
> On the flip side, suppose Alice is going to live wild and would like to
> use Andreas's lookup context.  I suspect this will be very common, just

I don't suspect that given my reasoning above.

> as it's very common in text editing a C program to use the author's
> indentation style regardless of how much you dislike it.  How does Alice
> get the appropriate lookup context?  Does she have to go look on a Wiki
> and then type it in by hand?  What?

IMHO think most of us would use one standard implementation of
LookupContext as I have described - and it carries no state so there is
nothing to transfer. Then if the Tweak *tools* use different logic then
fine by me, that was after all the idea of making this pluggable.

> I don't know what the exact transfer mechanism should be.  I suggest,
> though, that we integrate lookup contexts into the code base in a way
> that there is always an author-approved lookup context available, and we
> adjust monticello and fileout etc. to transfer these contexts.  Users do
> not have to use them, but they will have them when desired.  By default,
> the author-specified context should be used.

I still don't see the need for them but if I am wrong and the
LookupContext needs some import lists per namespace or something (which
IMHO will cause much more grief and confusion than suffering from having
to read an *occasional* fully qualified name) then fine then, we can add
that later.

Just to once again enforce why I think this is really not needed - when
I (soon) convert the Basic image into a bunch of namespaces (not sure
how many, roughly according to the category names up to the first dash)
then NOT A SINGLE qualified name will be visible in a SINGLE method in
the whole image. Because the class names are already unique. And I don't
think there are tons of these classes that we will rename to clash just
because we suddenly can, right?

So IMHO this is an imagined problem.
 
> > I would guess there are very, very few such objects (classes).
> 
> That is the current case, but I doubt the situation will stay like that
> once namespaces are ubiquitous.  And anyway, namespaces are there to be
> used.  If we truly decide that their usage will remain rare, then let's
> leave them out altogether.

I agree in principal but it still doesn't mean that we suddenly will be
overflowed with class names that clash.

> I expect they will get used, however.  Just look at all the classes with
> artificial prefixes on them such as RB or SM.  All of these would be
> better if namespaces were available.

Yes indeed! But there will still be relatively very few duplicate class
names.

> > In my current vocabulary a Namespace is a named Dictionary with symbols
> > as keys and objects as values. An "Andreas context" or what I
> > subsequently called LookupContext is an object that is used by Compiler
> > and Browser to both help resolving unqualified names when compiling
> > Smalltalk code and to help rendering code in a suitable fashion. 
> 
> Yes that is what I have meant.  In the simplest incarnation, a lookup
> context is simply a list of namespaces, but other things are possible.

No, in its SIMPLEST incarnation it just has the logic I have explained.
No lists required.

> -Lex

regards, Göran