"David A. Black" <dblack@wobblini.net> schrieb im Newsbeitrag
news:Pine.LNX.4.44.0409200600070.6220-100000@wobblini...
Hi --
> > > 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
···
On Mon, 20 Sep 2004, Robert Klemme wrote:
