Keep in mind that Monticello is "portable" to other dialects and changing the internal representation will break Monticello for other platforms ... FWIW, the implemenation of OrderedCollection in GemStone is very different than in Pharo or Squeak and it was possible for me to fudge the serializer to do the right thing for Monticello (which was serialize the OrderedCollections the way Pharo/Squeakl expected)... A similar thing could be done for Pharo if you wanted to change the shape of OrderedCollection... Dale On Fri, Sep 19, 2014 at 5:06 AM, 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). The question is this one: - would using FUEL would have resolved the problem or not? - 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