Hi Tim -

As much as I agree with the idea of reworking CompiledMethod in general, 
it seems to me we shouldn't mix up two otherwise unrelated issues. One 
issue is that of changing the source code representation from being four 
bytes in the compiled method to being a real object. The other one is to 
change CompiledMethod itself. The two are completely unrelated in my 
understanding - we could well have a better factored class 
CompiledMethod that uses four bytes at the end of the bytecodes to 
encode the source pointer and we can equally have a source object 
representation within the current CompiledMethods.

Mixing up these two just doesn't seem helpful to make in terms of being 
able to make progress. We now have a proposed solution for dealing with 
the source representation, I don't think there is any need to make this 
dependent on a complete overhaul of compiled method itself (in 
particular considering that there are some unanswered questions about 
speed/space tradeoffs in this area). And contrary, if someone would make 
the concrete proposal for a rework of CompiledMethod I would say let's 
not make this dependent on agreeing on a particular source code 
representation. In either case, both are valuable, yet independent 
problems to be solved. Mixing them up doesn't seem to add much value to 
the (already complicated) process of getting them adopted.

Cheers,
   - Andreas

tim Rowledge wrote:
> I've been looking at this code a while and whilst I congratulate Klaus 
> on his valiant attempt to solve the file size problem I think we need to 
> take a step back and try to clean things up a bit more.
> 
> The problem here is that we have an extraordinary mess in our source 
> pointer methods. It mostly stems from 'temporary' attempts to survive 
> the problems of having source pointed to by four bytes stuck to the end 
> of a nasty design of a hybrid object type that ought to have disappeared 
> in 1998 after I first wrote the code to convert them to proper objects. 
> If we stick any more patches on top of this nonsense we are in danger of 
> looking like a part decomposed ancient egyptian mummy.
> 
> Let's spend a little time and effort working out what we would like to 
> end up with and then a way to get there from here.
> 
> I would like to propose a fairly complete overhaul of CompiledMethod and 
> its friends. Get rid of the hybrid object format (which would simplify 
> the gc code a little too) and define CMs as
> bytecodes
> literals
> sourceaccess
> methodClass
> ...whatever other properties are needed...
> 
> ie a plain object with named instance variables. A slight alternative 
> that might be considered is for the literals to be indexed vars 
> following the named ones (think OrderedCollection if this is not 
> familiar to you).
> 
> We would lose the algorithmic gymnastics about last literal is the 
> class, second to last is the properties, first is the recipe for today's 
> soup dish, etc.
> 
> The source code access would be through any object understanding a small 
> protocol along the lines of 'get source', 'setSourceTo:' and .... err, I 
> think that's it. Again, back in '98 I demonstrated a system that used 
> this and had example accessors that used a file, an encoded file, a 
> plain string, a compressed string and a damp string. Using a database or 
> a networked method source server or a connection to another image which 
> held the source in some other way would all be possible.
> 
> The cost is a loss of backwards compatibility for the image. Maybe it 
> would be possible to make a vm that would run old images as well as new 
> ones but I suspect it would cost some performance and I'm sure it would 
> cost some tedious maintenance tax. You may not care about that but *I* 
> sure do! Maybe it would be better to just abandon the current image 
> lineage and jump ship to build this purely on top of Spoon? Maybe nobody 
> cares?
> 
> tim
> -- 
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Strange OpCodes: SEXI: Sign EXtend Integer
> 
> 
> 
>