[FIX][ENH] SortedCollection robustness & speedup
Florin X Mateoc
mateoc_florin at jpmorgan.com
Fri Apr 28 14:23:43 UTC 2000
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
More information about the Squeak-dev
mailing list
|