From: "David A. Black" Date: 2004-09-20T19:32:34+09:00 Subject: Re: Array#index block and rdetect Hi -- On Mon, 20 Sep 2004, Robert Klemme wrote: > > "Yukihiro Matsumoto" 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" > 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. > 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.) > > 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 :-) David -- David A. Black dblack@wobblini.net