Hello, I'd like to discuss about a problem found when loading classes with Fuel (for people who don't know it: http://rmod.lille.inria.fr/web/pier/software/Fuel).
Fuel can serialize a class either as a global or as a "regular" object. In the latter case, it saves the class with its compiled methods, including their bytecodes. (This was demonstrated in http://marianopeck.wordpress.com/2011/09/24/importing-and-exporting-packages-with-fuel/ ) Well, the issue I want to talk about happens when loading a class with a method that uses an inherited instance variable. In a short example: - define class A with instVars 'x' - define class B with a method that uses 'x'. - serialize B in a file - remove B from system - redefine A with instVars 'y x' - materialize B from the file -----> the bytecodes of B's method, that should refer to 'x', instead refer to 'y' (because inst vars are encoded in bytecodes just as indexes) Of course, there are variations of this problem: the variable was whether removed or renamed. Some solutions: 1) detect the change in a superclass and then: a) just raise an error b) compile based on attached source c) decompile parse tree from bytecodes, fix it, and generate the method. 2) serialize the parse tree *instead* of bytecodes, and always generate the method when materializing. I am thinking on the use case of package sharing, like Parcels. Note that since Fuel supports multiple strategies for serializing the same object, it is not necessary to choose just one option to fit in every use case. - I'm not sure, but I guess Parcels makes something like 1c). - The alternative 1a) doesn't require any compiler (in a bootstrap image is good) - I am tempted to explore 2), but not sure if that makes sense. I am curious about your opinions. Best regards, Martín
