On Mon, Nov 30, 2015 at 11:23 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Werner,

> On 30 Nov 2015, at 15:15, Werner Kassens <wkassens@libello.com> wrote:
>
> Hi,
> SortedCollection>>storeOn: seems to have a little problem since it does not store sortBlock and the used super-method (in Collection) uses #add: which uses sortBlock and their default uses #<=, hence if the elements are not comparable via #<=, but need a special sortblock, one gets an error on retrieving that collection. of course i can circumvent that tiny problem by defining #<= or using fuel, but i wonder whether i should report that on the bugtracker? btw perhaps some other collections with instanceVariables which do not define their own #storeOn: (eg Heap) could also have eventually some problems.
> werner

I am not so sure the #storeOn: / #readFrom: mechanism is still being maintained. I am not using it in any case, I thought it was mostly broken. I would be surprised if someone is still using it for real.

But I might be wrong. In that case there should be a suite of real unit tests that defines and maintains the expected behaviour. And then you would be right, we should fix it.

Yes, I have the same feeling. And I hate having such a general protocol like #storeOn: in our kernel objects. Store how? using which serializer?��
I think if this protocol is still used it should be much clearer.��
But as Sven said, I am not sure if this is still used and if it does, which code use it, who is the "serializer", etc...

--