Hi all!

First - thank you Avi for a good post. Always nice when someones sees
the "key". :)

Avi Bryant <avi at beta4.com> wrote:
> 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.

Yes. And this is exactly as it is today too. :)

> 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.

Yes. We can ignore the "shy" idea etc for now, doesn't really change the
basic needs.

> c) 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.

Right. So the source itself (in changes file, in sources etc) always
have the fully qualified name.
The trick is what we show in the browser panes and what we accept when
people press alt-s.

But as Andreas said - we can do whatever we like! :)

> 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.

Yeah, I think I agree. Do note though that we haven't "decided" on
syntax yet - even though I personally am leaning towards this syntax -
at least for compile time binding.

> 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 

Exactly, in place.

> 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.

Seems logical yes.

> 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.

Hmmm, yes - I haven't thought much about the actual implementation of
this yet.
 
> 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.

Mmm, yes, sounds reasonable. And the namespaces themselves ("Foo") would
then perhaps also be in the Smalltalk dictionary? I assume. So that:

	(Smalltalk at: #Foo::Bar) == ((Smalltalk at: #Foo) at: #Bar)
 
> 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.

Yes, seems like a logical next step. Need to formulate this a bit
clearer and also try a few usecases on it. For example - I would like to
hear about Andreas usecases.
 
> Avi

regards, Göran