On Apr 13, 2004, at 8:58 AM, Colin Putney wrote:

> For me, the crux of the issue is that I really don't like the idea of
> "rendering" the source differently in different contexts. I don't use 
> pretty
> printers for the same reason. That's not to say that there's no merit 
> in
> alternate ways of viewing and manipulating code, but that's not really 
> what
> your proposing.

I think this touches on an interesting side discussion, the answer of 
which may well inform how we want to approach namespaces.  When we look 
at source code for a method, what do we want to see?  I think there are 
two useful choices:

1. The exact string that was originally compiled to produce the current 
CompiledMethod
2. A string that, if it were compiled *now*, would produce an identical 
CompiledMethod

These are often the same thing, but not always.  For example, if I 
rename a class, any methods that refer to that class are suddenly out 
of date: recompiling their source will not produce a CompiledMethod 
that is equivalent to the one that is currently installed.  This can 
result in frustrating bugs, because you expect the source to be an 
accurate representation of the CompiledMethod.  It can also lead to 
cases where source filed out from a working image won't work when filed 
into a different one.  In these cases, I would prefer the source to be 
transparently updated to show the new class name (*without* losing my 
original formatting, however).  On the other hand, it's sometimes 
useful to go back to the "authorial intent" of the original source 
code, as when recompiling methods after adjusting the instance variable 
names of a class (though I seem to remember code from Andreas that 
makes do even without it).

Another way of asking the same question is, which is more 
authoritative, the source code or the bytecode? I personally incline 
towards the latter, because it captures the context in which the code 
is written as well as the code itself.  Which is why I like what Squat 
is doing: we should be filing bytecode in and out instead of source 
code, to more accurately transfer behavior (though we want to keep the 
source code as well or we lose formatting), and we should be giving 
UUIDs to classes (and any other objects referenced from 
CompiledMethods) for the same reason.


Avi