On 19.09.2014, at 14:06, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2014-09-19 13:55 GMT+02:00 Markus Fritsche <mfritsche@reauktion.de>: On 2014-09-19 11:35, Max Leske wrote:
- my implementation requires an extra instance variable in OrderedCollection to store the requested size. This extra instance variable will break Monticello (and possibly other tools) because Monticello uses OrderedCollections to load code and the particular way it uses them makes it impossible to change the number of instance variables on OrderedCollection. Also, all .mcz files written after the change will not be loadable by images without the new instance variable (same reason).
I might be a bit fundamentalistic, but shouldn't this (a using class making assumptions about the objects it's using) be considered a bug by object oriented standards?
Best regards Markus
It's not the using class per se. It's that MC is using a serialization framework sensitive to internal object representation (number/order of ivars).
IIRC, MC counts the number of inst vars in the implementation that is being loaded and then assumes that the current implementation has the same number of fields. It might actually be quite easy to simply use the min of the number of instance variables and ignore the rest. However, that would not address the problem of modified variable position (which is a problem at least in theory).
The question is this one: - would using FUEL would have resolved the problem or not?
Partly. You could tell Fuel to migrate to the new layout dynamically which would allow reading of the old format as well as reading and writing of the new format. It wouldnât be exactly âniceâ though.
- wouldn't a serialization using message sends to reconstruct the objects be more robust (future proof)? Of course the later requires the maintenance of a well defined API, so the robstness is relative. But at least, it would respect the object paradigm a bit more.
Nicolas