Hi all!

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

Just so everybody know - my "rendering" thingy uses the MethodNode so it
works fine without touching anything other than the actual global name.

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

I agree that there may be some good use of class UUIDs - though I am
still asking for a use case to understand. :)

I would like to know when a class is given a UUID and for how "long" it
stays the same.

For example, if I refactor and rename Banana to an abstract class Fruit
- is it the same class afterwards? I think not. I never did answer Craig
fully about my perceived problems with class UUIDs, but this is one of
them.

As a class evolves you could view it as a series of versions of ONE
class, at least as long as the name stays the same. But when the name
changes too - is it really still the same class?
 
> Avi

regards, Göran