On Apr 6, 2004, at 11:31 AM, Julian Fitzell wrote:

> Well I don't like that either.  Obviously the compiled method would 
> know specifically what class I was referring to, since I would have to 
> unambiguate (if necessary) when compiling, but is this proposal now 
> suggesting that the code I type is not the code that gets saved to the 
> .sources file?  This is a rather major deviation from the way things 
> work now and hardly a simple humble proposal.

That's the key, I think.  As I understand it, the main thrust of the 
proposal is this:

a) All references are to fully qualified names.  To enable proper 
exchange of code, this presumably means that the .changes file and .cs 
or .mcz fileouts include fully qualified names everywhere.
b) When writing a method, it is allowed to have short names in the 
code, but these are expanded when the method is accepted, in the same 
way that mistyped selectors are corrected.  If there are multiple 
possible expansions, the user will be asked to pick one.
b) The code browsers only display the fully qualified name in cases 
where it's necessary for disambiguation; otherwise, they magically show 
only the short form of the name.

Now, a) just requires some way of writing "fully qualified names", ie, 
the change to Scanner to allow Foo::Bar identifiers.  That's easy and I 
still think we should do it ASAP.
b) is also pretty easy to do; it's a reasonably simple modification to 
#bindingOf:, and there's a fair amount of precedent for similar 
mechanisms.

However c) is decidedly non-trivial to implement, and AFAICT the 
proposal rests completely on it.  To be acceptable, it would have to 
change the name in-place, not just as part of a pretty printer: I don't 
want to have my code reformatted just so I can see shorter class names. 
  Nobody has done anything like that yet, and I'd like to see it done 
before we spend too much time talking about.

It's also important to point out that b) and c) do represent a major 
change to the semantics of Smalltalk source code, in this way: 
normally, if I write an identifier Foo in a method, it resolves to 
either:

- a temp var named 'Foo'
- an instance variable named 'Foo'
- the value of some Association (in a class pool, shared pool, or 
environment) with key #Foo

However you implement namespaces (as one big dictionary with fully 
qualified keys, or as multiple dictionaries with short keys), this 
proposal doesn't conform to those rules, whereas the importing scheme 
Andreas was describing, does.  This may not be a major concern but it's 
worth thinking about.

Incidentally, I consider the separate namespace dictionaries orthogonal 
to the rest of this proposal; personally, I would prefer to see the 
full Foo::Bar names in the Smalltalk dictionary, since this would be a 
major win for forwards compatibility of existing tools.  It's going to 
be a *lot* more work to do it the other way.

So, Göran: if you want me, anyway, to seriously look at this proposal, 
why not whip up a prototype of a dynamically renaming code pane?  Once 
we've had a chance to play with it we'll be much better equipped to 
discuss the issues.

Avi