[Pharo-project] Fuel - class loading issue when superclass changed inst vars

Martin Dias tinchodias at gmail.com
Mon Mar 5 22:06:30 EST 2012


I'd like to discuss about a problem found when loading classes with Fuel
(for people who don't know it:

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

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
- I am tempted to explore 2), but not sure if that makes sense.

I am curious about your opinions.

Best regards,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20120306/6f98a1f1/attachment-0001.html>

More information about the Pharo-dev mailing list