Here's what I think.
copyFrom: start to: stop
" ANSI Smalltalk section 5.7.8.7, reorganised a bit.
Answer a new collection containing all of the elements of the
receiver between the indices start and stop inclusive in their
original order. The element at index start in the receiver is
at index 1 in the result, the element at index start+1 is at
index 2, etc. If stop < start, the new collection is emptyy.
Otherwise, the size of the new collection is the maximum of
(stop - start + 1) and 0. The parameters start and stop must
be positive integers.
Errors
If stop >= start and (start < 1 or start > the receiver's size).
If stop >= start and (stop < 1 or stop > the receiver's size).
"
((start isKindOf: Integer) and: [start positive])
ifFalse: [start error: 'not a positive integer'].
((stop isKindOf: Integer) and: [stop positive])
ifFalse: [stop error: 'not a positive integer'].
^stop < start
ifTrue: [self copyEmpty]
ifFalse: [(start between: 1 and: self size)
ifFalse: [start error: 'index out of range'].
(stop between: 1 and: self size)
ifFalse: [stop error: 'index out of range'].
self from: start to: stop collect: [:each | each]]
allButFirst
^self allButFirst: 1
allButFirst: count
^self copyFrom: count + 1 to: self size
allButLast
^self allButLast: 1
allButLast: count
^self copyFrom: 1 to: self size - count
first: count
"(x first: n) , (x allButFirst: n) = x and: [(x first: n) size = n]"
^self copyFrom: 1 to: count
last: count
"(x allButLast: n) , (x last: n) = x and: [(x last: n) size = n]"
^self copyFrom: self size - count to: self size
See the comments in #first: and #last: ?
In order to program effectively, I need operations with *simple*
specifications.
"seq first: n returns the first n elements of seq or it's an error"
"seq last: n returns the last n elements of seq or it's an error"
This has the virtue of making these pretty redundant operations fully
consistent with #copyFrom:to:
On Fri, 30 Aug 2019 at 19:34, Julien <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?
>
> Should #allButFirst: with an argument greater than the collection size
> raise an error
>
> Or
>
> Should #allButFirst: with an argument greater than the collection size
> returns an empty collection ?
>
> I asked a few people about it @ ESUG and it appears that the expected
> behaviour from #allButFirst: is not the same to all people.
>
> We need to decide so we improve consistence of collections.
>
> And then, we need to document that with a test :-).
>
> Cheers.
>
> Julien
>
> ---
> Julien Delplanque
> Doctorant à l’Université de Lille
> http://juliendelplanque.be/phd.html
> Equipe Rmod, Inria
> Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq
> Numéro de téléphone: +333 59 35 86 40
>
>
