On 30. 8. 2019 11:56, Ben Coman wrote:
On Fri, 30 Aug 2019 at 15:34, Julien <julien.delplanque@inria.fr <mailto:julien.delplanque@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