On Tue, Mar 6, 2012 at 4:06 AM, Martin Dias <[email protected]> wrote:

> 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
>
>
I guess you forgot to say B is subclass of A or something like that?



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


-- 
Mariano
http://marianopeck.wordpress.com

Reply via email to