> On 16-03-2017, at 12:56 PM, Eliot Miranda <[hidden email]> wrote:
> IIRC, the source is encoded in the method trailer bytes. Currently there's no encoding type for WideString. But Igor's CompiledMethodTrailer reimplementation makes it easy to add new types. So it should only be a little work to add an encoder and decoder for WideStrings.
The *nicest* way to fix this would have been an actual instvar (and separate objects for the literals, bytecodes etc) instead of magic bytes; we did that at Interval (amongst other similar approaches I’ve read about) and it made it really easy to have simple string, a file reference, a database key, a URL, a compressed string etc.
Note that AdditionalMethodState provides another way to add inst vars. One can subclass AdditionalMethodState to add inst vars. i think I even when as far as adding the compiler support to access the inst vars from AdditionalMethodState implicitly (rather like accessing context temps in the lower right hand pane of the debugger).
The thing you're not mentioning is that adding the additional inst var for bytes and literals adds significant overhead in the in terpreter. Either the method variable splits into a byte codes and a literals variable, both of which have to be set on activation and return, or one adds an indirection on each byte code and/or literal fetch, indirecting through the method object to access byte codes and/or literals.
So for as long as we have an interpreter VM the current flat representation, while ugly if viewed from one point of view, works really well for the interpreter, and is quite nice when viewed from this other point of view.
But yes, Igor’s work makes it practical to do much the same thing albeit in a rather roundabout way.
Remember that Dan implemented eliminating sources and disassembling with temp names by compressing the temp names to the method trailer.