On 30. 8. 2019 11:56, Ben Coman wrote:
On Fri, 30 Aug 2019 at 15:34, Julien <julien.delplan...@inria.fr
<mailto:julien.delplan...@inria.fr>> wrote:
Hello,
I opened that issue: https://github.com/pharo-project/pharo/issues/4442
And I think to fix it we need to actually discuss about what we want.
#allButFirst: behaves differently depending on the actual type of
sequenceable collection when argument is greater than collection size.
For instance:
#(1 2) allButFirst: 3. "PrimitiveFailed signaled"
(LinkedList with: 1 with: 2) allButFirst: 3. "PrimitiveFailed signaled"
(OrderedCollection with: 1 with: 2) allButFirst: 3. "an
OrderedCollection() »
The question is then, who is right?
Its worthwhile to at least survey other Smalltalks.
For Visualworks...
#(1 2) allButFirst: 3. "==> #()"
(OrderedCollection with: 1 with: 2) allButFirst: 3. "==>
OrderedCollection ()"
(LinkedList with: Link new with: Link new ) allButFirst: 3.
"raises an error Subscription out of bounds error"
and also...
(LinkedList with: Link new with: Link new ) allButFirst: 2.
"raises an error Subscription out of bounds error"
I feel that proceeding-without-iterating is nicer than
showing-an-application-error.
It provides the opportunity to not-check the number elements or wrapping
error handling around it - i.e. less code if its not important.
That's what I think as well.
If its important not to exceed the number of elements, then that check
can be explicitly coded.
cheers -ben