From: "David A. Black" <dblack@...>
Date: 2004-09-20T19:39:49+09:00
Subject: Re: Array#index block and rdetect

Hi --

On Mon, 20 Sep 2004, Yukihiro Matsumoto wrote:

> Hi,
> 
> In message "Re: Array#index block and rdetect"
>     on Mon, 20 Sep 2004 11:12:12 +0900, "David A. Black" <dblack@wobblini.net> writes:
> 
> |>   * Enumerable#each_index should be removed (yes/no)
> |
> |There is no Enumerable#each_index -- nothing to remove.  
> 
> I meant each_with_index.

In that case, yes.

> |>   * How about other enumerable classes?
> |
> |I think the idea of every enumerable class having an "index", defined
> |as part of that class, is possibly useful.  For hashes it could be the
> |keys; for arrays, the integer index; for files, the line number.  In
> |some cases (like index/key for hashes), it might be redundant.  But it
> |might open up some good possibilities.  
> 
> The most consistent (but incompatible) change would be:
> 
>   * leave Enumerable#each_with_index unchanged.

Question: if "index" is a basic Enumerable thing, why is there no
Enumerable#each_index?  (My preference would be to push
#each_with_index down to the individual classes too; but in any case,
I'm curious about it.)

>   * make Hash#each as alias of Hash#each_value
>   * redefine Hash#each_with_index as alias of Hash#each_pair

Actually it might be better to have Hash#each_with_index yield (value,
key) (like Florian's idea), since the value is the element and the key
is the index.  However, calling it "index" instead of "key" then just
becomes arbitrary, and has a "legacy" feel to it.  

> But this change may break many programs.

The #each change might, but I don't think I've ever seen anyone use
Hash#each_with_index so that probably wouldn't matter.  


David

-- 
David A. Black
dblack@wobblini.net