Gemstone 3.x -- changes to SortedCollection break some code ...

> In 2.x, the methods
>    indexOf:
> and thus
>    remove:
>
> worked as they do for OrderedCollection.    They searched for the object and removed it.
>
> In 3.x the method
>    indexOf:
> uses the sort block and a binary search to find the object and thus remove it.
>
> The problem is if the content of the object that affects the sort sequence changes you can no longer remove it from the SortedCollection.
> I can see the logic of the change, but it does tie ones hands when object content changes, and the change was not noted in the release notes.
>
> My problem is that the object content changes with the object existing in multiple SortedCollection's, and then the code runs around and removes and re-add's the object in each -- non-trivial to re-order the sequence of events.
>
> I will probably add a special remove, its simpler.
>
> --
> Dennis Smith                                  +1 416.798.7948
> Cherniak Software Development Corporation   Fax: +1 416.798.0948
> 509-2001 Sheppard Avenue East        [hidden email]
> Toronto, ON M2J 4Z8              sip:[hidden email]
> Canada                     http://www.CherniakSoftware.com
> Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP
>
> --
> GemStone-Smalltalk mailing list
> Unsubscribe: send e-mail with the word "unsubscribe" in body (without quotes) to:
> [hidden email]
> Archive: http://forum.world.st/Gemstone-Customers-f1461796.html

> Hi Dennis,
>
> This initially sounded familiar but on further investigation I'm not so sure.
>
> In 2010 SortedCollection>>#'includes:' was changed to do a linear search rather than a binary search since the #'<=' message might not be consistent with the #'=' message. (We also added #'binarySearchIncludes:' to provide the previous fast search. See bug #40575 in 2.4.4, 2.5.0, and 3.0.)
>
> From what I've been able to tell reading the source code, the #'indexOf:' method in SortedCollection has not changed significantly since 2004 (the beginning of the 64-bit code base).
>
> James
>
> On Jan 17, 2013, at 5:44 AM, Dennis Smith wrote:
>
>> In 2.x, the methods
>>   indexOf:
>> and thus
>>   remove:
>>
>> worked as they do for OrderedCollection.    They searched for the object and removed it.
>>
>> In 3.x the method
>>   indexOf:
>> uses the sort block and a binary search to find the object and thus remove it.
>>
>> The problem is if the content of the object that affects the sort sequence changes you can no longer remove it from the SortedCollection.
>> I can see the logic of the change, but it does tie ones hands when object content changes, and the change was not noted in the release notes.
>>
>> My problem is that the object content changes with the object existing in multiple SortedCollection's, and then the code runs around and removes and re-add's the object in each -- non-trivial to re-order the sequence of events.
>>
>> I will probably add a special remove, its simpler.
>>
>> --
>> Dennis Smith                                  +1 416.798.7948
>> Cherniak Software Development Corporation   Fax: +1 416.798.0948
>> 509-2001 Sheppard Avenue East        [hidden email]
>> Toronto, ON M2J 4Z8              sip:[hidden email]
>> Canada                     http://www.CherniakSoftware.com
>> Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP
>>
>> --
>> GemStone-Smalltalk mailing list
>> Unsubscribe: send e-mail with the word "unsubscribe" in body (without quotes) to:
>> [hidden email]
>> Archive: http://forum.world.st/Gemstone-Customers-f1461796.html
>
> --
> GemStone-Smalltalk mailing list
> Unsubscribe: send e-mail with the word "unsubscribe" in body (without quotes) to:
>  [hidden email]
> Archive: http://forum.world.st/Gemstone-Customers-f1461796.html

> Dennis,
>
> You are right, there was a change. Previously #'indexOf:' was implemented to use #'_indexOfIdentical:'. This is inconsistent with ANSI which we understand wants an equality comparison.
>
> It appears that the fix in 2.4 (mentioned in the release notes for 2.4, p. 34, September 2009, Bug #39796, revision 22095) was to remove the #'indexOf:' method entirely so that the inherited method was used (which does a linear search). An alternate fix in 3.0 (revision 22891, apparently not documented) was to implement SortedCollection>>#'indexOf:' as #'indexOfValue:'  which had a binary search.
>
> I'm not sure about the trade-off between performance and robustness here. It does seem reasonable to expect that elements in a SortedCollection will not change their sort value after being added, but it certainly could happen.
>
> James
>
> On Jan 17, 2013, at 8:09 AM, James Foster wrote:
>
>> Hi Dennis,
>>
>> This initially sounded familiar but on further investigation I'm not so sure.
>>
>> In 2010 SortedCollection>>#'includes:' was changed to do a linear search rather than a binary search since the #'<=' message might not be consistent with the #'=' message. (We also added #'binarySearchIncludes:' to provide the previous fast search. See bug #40575 in 2.4.4, 2.5.0, and 3.0.)
>>
>>  From what I've been able to tell reading the source code, the #'indexOf:' method in SortedCollection has not changed significantly since 2004 (the beginning of the 64-bit code base).
>>
>> James
>>
>> On Jan 17, 2013, at 5:44 AM, Dennis Smith wrote:
>>
>>> In 2.x, the methods
>>>    indexOf:
>>> and thus
>>>    remove:
>>>
>>> worked as they do for OrderedCollection.    They searched for the object and removed it.
>>>
>>> In 3.x the method
>>>    indexOf:
>>> uses the sort block and a binary search to find the object and thus remove it.
>>>
>>> The problem is if the content of the object that affects the sort sequence changes you can no longer remove it from the SortedCollection.
>>> I can see the logic of the change, but it does tie ones hands when object content changes, and the change was not noted in the release notes.
>>>
>>> My problem is that the object content changes with the object existing in multiple SortedCollection's, and then the code runs around and removes and re-add's the object in each -- non-trivial to re-order the sequence of events.
>>>
>>> I will probably add a special remove, its simpler.
>>>
>>> --
>>> Dennis Smith                                  +1 416.798.7948
>>> Cherniak Software Development Corporation   Fax: +1 416.798.0948
>>> 509-2001 Sheppard Avenue East        [hidden email]
>>> Toronto, ON M2J 4Z8              sip:[hidden email]
>>> Canada                     http://www.CherniakSoftware.com
>>> Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP
>>>
>>> --
>>> GemStone-Smalltalk mailing list
>>> Unsubscribe: send e-mail with the word "unsubscribe" in body (without quotes) to:
>>> [hidden email]
>>> Archive: http://forum.world.st/Gemstone-Customers-f1461796.html
>> --
>> GemStone-Smalltalk mailing list
>> Unsubscribe: send e-mail with the word "unsubscribe" in body (without quotes) to:
>>   [hidden email]
>> Archive: http://forum.world.st/Gemstone-Customers-f1461796.html