Comment on this RCR (edit wiki page) | RCRchive home

RCR 204: Negative arg for Array#first and

submitted by flgr on Thu Jan 29 2004 12:48:58 PM -0800

Status: pending

Abstract

Array#last and Array#first should accept negative arguments relative to the end of the Array.

Problem

Currently Array#[] and Array#last / Array#first are inconsistent in their handling of negative arguments. It would be expected for both of them to work analogous in this case.

Proposal

Handle a negative argument to these constructs just like in Array#[]. (Add the length of the Array to it to make it relative to the end of the Array.)

Analysis

This would also add the rest() function of LISP (which was already wanted by some in the standard Ruby in the past) by generalising something which is already there.

There would be no incompatibilities caused by this because negative lengths previously had no meaning in this construct. (They used to raise an exception.)

Implementation

class Array
  def first(amount = 1); self[0 ... amount]; end
  def last(amount = 1); self[-amount .. -1]; end
end

if __FILE__ == $0
  ary = [1, 2, 3, 4, 5]
  p ary.first(2)
  p ary.last(-2)
end

Vote for this RCR

Strongly opposed [4]
Opposed [2]
Neutral [2]
In favor [1]
Strongly advocate [2]

Change the status of this RCR to:

accepted

rejected

withdrawn

What do you mean by "inconsistent"? The optional argument to "first" and "last" means number of items requested, not offset. For example, the second value for "ary[pos,len]" does not accept negative value.

-- matz.

I agree with matz. A negative parameter only makes sense when you are asking for an offset. When you are asking for the number of items to return, a negative number doesn't really apply.

-- Jamis

I think there shouldn't be a distinction between indices and lengths in this case -- I think #first and #last should really use Range fetches instead which would avoid also having to accept arr[1, -5]. (which doesn't seem to make sense to me)

I think it makes sense to think about the argument as an amount of values you're asking for which can be relative to the total amount of values available.

-- flgr

I couldn't see any reason for your "should". Can you show us why do you think they should be no distinction? I feel offsets and number of items are different, even though they are related (e.g. 0 .. number of items = range for those items). When I describe the "first(n)" method, it should be: "retrieve first n items from the array"; not "retrive items from offset zero to offset n (including n)", which makes me somewhat confusing.

- matz.

I think I see what you're getting at -- so this is about not exposing features of underlying implementations, because the underlying implementation might change and make it harder to make those features available?

I still think this would a nice compromise between another pair of methods and not having the features they would offer at all without introducing any icky flags and the like, but I think I can understand if you choose to reject this because of the above reason. (Though it would be a bit sad.)

-- flgr

When I request n items from an array, I think and I expect, n must be a natural number (non zero, positive integer). Respecting *my* expectation is the key of Ruby's design. If you want to persuade me, you have to give me rationale better than "compromise". How often do you want to retrieve "items but last n"? If you want often, it's good to have another pair of methods. If you want rarely, ary[0..-n] would be suffice.

-- matz.

Back to RCRchive.

RCR Submission page and RCRchive powered by Ruby, Apache, RuWiki (modified), and RubLog