On 11/30/18 3:33 AM, Trussardi Dario Romano via Glass wrote:
> Ciao,
>
> i work with SIXX to save objects data from Pharo
>
> and load these data in another Pharo version or into Gemstone database.
>
>
> Now SIXX cannot store/load context object.
>
> But i have some SortedCollection instances with relative sortBlock.
>
>
>
> I think to manage this problematic with:
>
> 1) define in the class method the method:
>
> defaultSortBlock
>
> ^ self evaluate: ' [ a: b: | a data >= b data ]'
>
> 2) when access to the sortedCollection instance
>
> i testing se the relative sortBlock is not setting and do:
>
> aSortedCollection sortBlock ifNil:[ aSortedCollection sortBlock: self class defaultSortBlock ]
>
>
> It's right ?
Yeah this is a difficult problem and your solution is a fine workaround
as long as you don't have multiple sortBlocks to deal with. The
alternatives involve more complicated general solutions:)
I would note that you don't have to use #evaluate: to create your block.
The following should work just as well:
defaultSortBlock
^ [ a: b: | a data >= b data ]
... but at the end of the day, you end up with a functionally equivalent sort block, so changing anything is probably not necessary.
> How should I behave in these cases
>
> I have seen that a relative problematic also concerns the update at a new version of gemstone,
>
> but in this case i have the source code of the sortBlock and i need only to recompile it.
Ah yes, this is a good point ... Depending upon the version of GemStone
that you are upgrading to, you can send the message #recompile to a
simple block to recreate the block ( (look for ExecBlock>>recompile).
Dale
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Locked
