From: Robert Klemme <bob.news@...>
Date: 2004-09-20T21:54:40+09:00
Subject: Re: Array#index block and rdetect


"David A. Black" <dblack@wobblini.net> schrieb im Newsbeitrag
news:Pine.LNX.4.44.0409200324260.11614-100000@wobblini...
> Hi --
>
> On Mon, 20 Sep 2004, Robert Klemme wrote:
>
> >
> > "Yukihiro Matsumoto" <matz@ruby-lang.org> schrieb im Newsbeitrag
> > news:1095650370.096071.21408.nullmailer@x31.priv.netlab.jp...
> > > 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.
> > >
> > > |>   * 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.
> >
> > Sorry, David, I stongly disagree: IMHO an index does only make sense
in a
> > class that maintains a certain order (such as Array).  A Hash does not
> > have a particular order and thus Enumerable#each_with_index is the
> > appropriate thing; here the index is valid just for the current
iteration
> > and can be used for printing or whatever.  But I would not want to add
an
> > index to a Hash.
> >
> > 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.

> > 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.

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.

> > >  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.
> > >   * make Hash#each as alias of Hash#each_value
> > >   * redefine Hash#each_with_index as alias of Hash#each_pair
> > >
> > > But this change may break many programs.
> >
> > Yeah, that's true.  What about a method in Hash that changes method
> > behavior to the array compatible style?  That way no old code is
broken
> > and you can purposely change a Hash's look if you need to make sure
that
> > this Hash can be interchangeably used with an Array.
>
> It's called #to_a :-)  I think that's better than having a switch that
> changes behavior.  We're going to start hearing a lot of "for
> historical reasons..." and "glued on as an afterthought..." otherwise
> :-)

Yeah, you're right.

Kind regards

    robert