On Sat, 17 Feb 2001, Mathieu Bouchard wrote: > On Fri, 16 Feb 2001, David Alan Black wrote: > > On Fri, 16 Feb 2001, Mathieu Bouchard wrote: > > > Sorry, not really... > > > a = [2,3,5,7] > > > a[2] #=> 5, one element in single mode > > > a[2..2] #=> [5], one element in multiple mode > > irb(main):001:0> a = [1,2,3,4] > > [1, 2, 3, 4] > > irb(main):002:0> a[1].type > > Fixnum > > irb(main):003:0> a[1..1].type > > Array > > I thought the proposed extension to #at would behave like that too -- ? > > What do you mean, would behave like that? The proposed extension would > make #at(*indices) return an array, but #at cannot distinguish a list of > one element from a single value -- it's still a parameter list. There is > no equivalent in the #[] realm, which can distinguish a one-element range > from a single element fetch anytime. I think part of the original discussion was whether to extend #at so that it *did* behave differently when given more than one parameter: [1,2,3].at(0) => 1 [1,2,3].at(1,2) => [2,3] Mike Wilson had questioned whether the first of those two should return a single value or an array: [1,2,3].at(0) => [1] Matz had said: > For consistency, at(0) might be better to return an array, but it's > incompatibility, which I don't want to incorporate. I took this to mean consistency across all uses of (the extended) #at -- namely, that the most consistent thing would be for it always to return an array. My subsequent point was that it might not actually be so inconsistent, broadly taken, since there's a precedent for the idea of an array fetch that returns a single value for a single-value fetch and an array for a range-fetch: the current behavior of #[]. (I'm retracing this in hopes of, as usual, having the little lightbulb go off... it isn't happening yet... Of course, the little lightbulb loves watching me hit the <send> button.... :-) David -- David Alan Black home: dblack / candle.superlink.net work: blackdav / shu.edu Web: http://pirate.shu.edu/~blackdav