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

Hi --

On Mon, 20 Sep 2004, Robert Klemme wrote:

> > > Or did you mean to use the hash key as index?
> >
> > Yes.  I certainly didn't mean numerical indexes for hashes; that's the
> > whole problem (well, part of the problem) with Hash#each_with_index in
> > the first place.  Also, by "defined as part of that class", I meant
> > defined according to the needs of that class, so that for arrays it
> > would be integers, for hashes the keys, etc.
> 
> Ok, I see.  I wouldn't change the behavior of #each_with_index since that
> is likely to break a lot code.  Read on for my suggestion.

I honestly doubt it would break much code.  I have never seen
Hash#each_with_index used.  

> > > That would be a different
> > > story...  While that would make sense for Array and Hash I think there
> are
> > > a lot Enumerables out there that do not correspond easily to
> associative
> > > storage, for example a Enumerable that emits arbitrary many random
> numbers
> > > in its #each method.
> >
> > That problem is already there, in the sense that such an object
> > already has an #each_with_index method.  I'm trying to make sense of
> > the notion of "index" as part of Enumerable, though it's quite
> > possible that *not* having it be part of Enumerable would be better --
> > and then classes could either define index-related methods or not.
> > (That's what I meant originally about leaving #each_with_index up to
> > the individual classes, like #each_index.)
> 
> Well, I think the main problem here is confusion of two different things:
> numerical indexing (I'll use the term "index" for this) and lookup keys
> (called "keys" hereafter).
> 
> In my understanding Enumerable#each_with_index just goes through the
> enumerable and counts an index which can be used for printing or counting
> or whatever.  So I would not change this method.  These indexes are purely
> per enumeration and can change for any number of reasons.

I have the same understanding, and that's why I *would* change this
(frequently useless) method :-)  See below....

> Additionally we should have Array#each_with_key and Hash#each_with_key and
> AnyOtherLookupCollection#each_with_key (or call it #each_pair) that yield
> key, value pairs.  In the case of an Array the keys happen to be identical
> with the indexes of a forward iteration but in case of a Hash keys are
> hash keys and thus different from indexes.
> 
> I think the problem stems from the fact that we want to handle indexes and
> keys with a single set of methods wile in fact these are different things
> that only occasionally overlap.

Actually my suggestion earlier was to detach the concept of "index"
from Enumerable so that each enumerable class could define it as it
wanted to.  That's why I'd like to push #each_with_index out of
Enumerable.  It's the only "index" method in Enumerable, and I think
it can lead to too specific a concept of indexing for classes like
Hash where numerical indexes are essentially meaningless.  (I guess
this might change if hashes become ordered....)

I would prefer, in other words, for key and index to overlap in Hashes
as well as Arrays.  I just don't see enough advantage in having this
semi-magic #each_with_index at the level of Enumerable (semi-magic in
the sense that it does a kind of implicit to_a). 

Or, if index always means a (to_a-based) numerical index, then
#each_index should be in Enumerable, and not left to the individual
classes.  Then it would be clearer that index == 0-origin, possibly
meaningless (for unordered collections), numerical index.  Classes
that specialized from this could either re-use the name index (for
example, a 1-origin collection), or introduce a set of methods with a
new name/concept (like key).  


David

-- 
David A. Black
dblack@wobblini.net