Source code or bytecode? (was Re: A little namespace "proposal")

Colin Putney cputney at wiresong.ca
Wed Apr 14 15:01:46 UTC 2004


Quoting goran.krampe at bluefish.se:

> > 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). 
> 
> Eh, "the code that will now compile" sounds like you think the source
> (the actual String of characters that the Compiler eats) has changed. It
> has not.
> 
> > 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.
> 
> No, if I am to be petty with words this is not correct. I repeat - the
> exact same String that was fed into the Compiler the first time will be
> fed into the Compiler the second time. The only thing that has changed
> (perhaps this is what you wanted to say) is what is *showed* in the
> browser.

Please, Goran. Don't just repeat the same thing over and over. I *do* understand
what you have proposed. In this thread we are explicitly talking about what is
displayed in the browser.

Avi asked what we want to be displayed when we browse the source code of a
method:

1) The exact string that the author typed in to produce the active
CompiledMethod.

2) The string that, if compiled now, would produce the active CompiledMethod.

My objection to your proposal is that it introduces new opportunities for these
strings to be different, and that it often displays neither of these things. In
the case of unambiguous class references, what is displayed is neither what was
compiled, nor what will be compiled. 

I understand that you are trying to keep things as close to the current
behaviour as possible, but it seems too "tricky" to me. What is presented to
the user is not what is going on under the hood, and I think this will
eventually cause confusion. 

Colin




More information about the Squeak-dev mailing list