From: Joel VanderWerf <vjoel@...>
Date: 2002-09-20T12:04:34+09:00
Subject: Re: select and select

Yukihiro Matsumoto wrote:
...
> We want to have a new method to replace "indices", because of
> inconsistency between "indices" (or "indexes") and "index". "index"
> returns index of a value, "indices" returns values corresponding to
> indices.
> 
> A new method (say "quux" for example) should satisfy
> 
>   * obj.quux(a,b,c) returns [obj[a],obj[b],obj[c]] for all indexable
>     collections (i.e. Array, Hash, MatchData and Struct), perhaps
>     except for String, which is mere string of characters rather than
>     indexable collection.  So preferably it should sound natural both
>     for arrays, hashes and others.
> 
>   * obj.quux() either returns an empty array or causes exception, due
>     to the case like obj.quux(*ary) where ary is an empty array.

I have to agree, that's the right behavior. So we will have

[0,1,2,3,4].entries   #==> [0,1,2,3,4]
[0,1,2,3,4].quux      #==> []            (or an exception)

So far, so good. But what should the name be? Both "items" and 
"elements" seem too close to entries in their natural language meaning. 
There were good arguments against using "at" (doesn't seem to fit 
hashes, reduces efficiency of Array#at).

Does "indexable collection" mean anything that responds to #[] ?

If so, then proc and method objects come into play, and the perfect name 
would make sense for them as well. But in this case the quux method 
would be just another way of writing #map, so maybe this isn't important 
to consider after all.

What about these?

   at_indices   (too long, ugly)

   sample       (not very clear)

   pick         (too close to select)

I guess I still like select best.