Quoting Avi Bryant <avi at beta4.com>:

> 
> On Apr 13, 2004, at 2:15 PM, Colin Putney wrote:
> 
> > What I dislike about Goran's proposal is that it introduces more new
> > opportunities for divergence between what was compiled and what will 
> > now
> > compile to the same bytecode. What's worse, this divergence will occur 
> > as a
> > side effect of actions not directly related to namespaces.
> 
> I don't think that's true, at least not as I understand the proposal.  
> The context is bidirectional: yes, you can change the context of the 
> browser so that the same string will resolve to a different class.  
> However, that browser will automatically update all the source it 
> displays so that it's consistent with the new context: it never shows 
> the original string that was typed in, but a string that will resolve 
> to the same fully qualified name in the current context.  So I don't 
> see where the divergence comes in.

Right. There's no divergence between the code displayed and the active
CompiledMethod.

But there is a divergence between what was originally compiled (your #1), and
what is being displayed (the code that will now compile to the active bytecode,
your #2). 

At the same time, "changing the context of the browser" is implicit. If I file
in a package that introduces ambiguity in an existing compiled method, the
source displayed by the browser will be silently and automatically updated so
that while it will produce the same bytecode in the new context, it no longer
matches what was originally compiled to product that byte code. IOW, your #1
and #2 no longer match.

In my scheme, you can only change the context explicitly - effectively, you say
"recompile package X using this new namespace." This might result in the source
code being updated, but since you're also recompiling as well, #1 and #2 are
still identical. And changing the namespace of an existing package is likely to
be less common than adding a new namespace to the image, so the situation will
come up less often.

Colin