Hi Andres,

At first I did not realize what was failing. The example with 3 at 3 works just
fine (although the index is 13 not 26 (there are only 25 elements) like you
said).

The part that is still failing is
s includes: #garbage.

You are right, #includes is a generic message and it should probably work even
for a SortedCollection and an incompatible object.
I would contend that #indexOf: should be allowed to fail for an incompatible
object. A SortedCollection is conceptually different from an OrderedCollection.
It has no external notion of index independent of the sort criteria.

I think your suggestion to use exceptions here for #includes: is the right way
to do it. So, what do you think of:

includes: anObject

     ^[(self indexOf: anObject) ~~ 0] on: Error do: [:ex | ex returnWith: false]



Florin



(See attached file: sortedCollection.1.cs)





avalloud at entrypoint.com on 04/27/2000 06:53:09 PM

Please respond to squeak at cs.uiuc.edu

To:   squeak at cs.uiuc.edu
cc:   (bcc: Florin X Mateoc)
Subject:  Re: [FIX][ENH] SortedCollection robustness & speedup




Hi Florin.

> I am afraid your implementation of the #includes: method only works for the
> particular cases where the object is arithmetically compared directly.

Or when the object provided is compatible with the operations in the sort block.

> I took a stab at (re)implementing #includes: and #indexOf: for the
> SequenceableCollection classes.
>
> !SortedCollection methodsFor: 'accessing' stamp: 'fm 4/26/2000 15:08'!
>
> indexOf: newObject
>      | index low |
>      low := self indexForInserting: newObject.
>      sortBlock isNil

Hmmm... how about ifNil:ifNotNil:...

>           ifTrue: [
>                index := low -1.
>                ^[index >= firstIndex and: [(array at: index) = newObject] ]
>                     ifTrue: [low - firstIndex]
>                     ifFalse: [0]]
>           ifFalse: [
>                index := low -1.
>                [index >= firstIndex and:
>                [(sortBlock value: (array at: index) value: newObject) and:
>                [sortBlock value: newObject value: (array at: index)]]]
>                     whileTrue:
>                          [(array at: index) = newObject
>                               ifTrue: [^index + 1 - firstIndex].
>                          index := index - 1].
>                index := low.
>                [index <= lastIndex and:
>                [(sortBlock value: (array at: index) value: newObject) not and:
>                [(sortBlock value: newObject value: (array at: index)) not]]]
>                     whileTrue:
>                          [(array at: index) = newObject
>                               ifTrue: [^index + 1 - firstIndex].
>                          index := index + 1].
>                ^0]! !

Unfortunately, the example I provided in my previous message will fail with this
method too, because it relies on #indexForInserting: and also because it assumes
anObject will be compatible with sortBlock. There is no way to predict that what
will be provided through #indexOf: will respond to messages probably sent in the
sortBlock (remember that the sortBlock is used in #indexForInserting:). It is
not
possible to predict the protocol of this object beyond things like #=.

Andres.





-------------- next part --------------
A non-text attachment was scrubbed...
Name: sortedCollection.1.cs
Type: application/octet-stream
Size: 264 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20000428/7bb60b08/sortedCollection.1.obj