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