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


"David A. Black" <dblack@wobblini.net> schrieb im Newsbeitrag
news:Pine.LNX.4.44.0409200600070.6220-100000@wobblini...
> 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.

Possibly true.

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

Well, you can use numbers as keys today already. :-)

> I would prefer, in other words, for key and index to overlap in Hashes
> as well as Arrays.

Ok, that's another resolution of the confusion.  That would essentially
mean dropping of what I called "index" and leaving that to the user if
he/she ever needs it.  That's ok with me, too, if it doesn't break too
much code.  But in fact Hash#each_with_index seems a rather esoteric
application so that's probably the right way to go.

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

I don't view it as "implicit to_a" and thus no implicit magic.  I view it
simply as counting elements.  Btw, there is no array conversion involved
which can be proven like this:

>> class Foo
>>   include Enumerable
>>   def each; loop { yield 1 } end
>> end
=> nil
>> Foo.new.each_with_index {|a,i| p [i, a]; break if i > 10}
[0, 1]
[1, 1]
[2, 1]
[3, 1]
[4, 1]
[5, 1]
[6, 1]
[7, 1]
[8, 1]
[9, 1]
[10, 1]
[11, 1]

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

I prefer your first suggestion.  So +1 for dropping
Enumerable#each_with_index in favor of Array#each_with_index (yield
element, numeric index) and Hash#each_with_index (yield value, key).

Now the only thing left is, we have to get Matz to agree. :-)

Kind regards

    robert