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