From: "trans. (T. Onoma)" Date: 2004-09-19T23:20:08+09:00 Subject: Re: Array#index block and rdetect On Sunday 19 September 2004 07:59 am, Robert Klemme wrote: > "trans. (T. Onoma)" schrieb im Newsbeitrag > news:200409190606.22327.transami@runbox.com... > > > Tiny RCR suggestion: > > > > Array#index optionally take a block like Enumerable#detect does. > > > > ['a','b','c'].index{|e| e == 'b'} # => 1 > > ['a','b','c'].index{|e| e == 'c'} # => 2 > > ['a','a','a'].index{|e| e == 'a'} # => 0 > > ['a','a','a'].index{|e| e == 'b'} # => nil But this Array#index {block) is acceptable, yes? > > Question: why isn't #index a method of Enumerable, considering > > #each_with_index is? (FYI: 'alias find detect'.) > > Because not all collections keep a definite order as Array does. For > example, hashes do not keep any certain order of elements hence indexing > does not make any sense. Couldn't the index of a hash be considered the key? So the block of #index when applied is the value. i.e. {:a=>'a',:b=>'b',:c=>'b'}.index{|e| e == 'b'} # => :b But then, of course, there would be no telling which key you might get. Suppose that could be considered a problem. > > Lastly, what about an rdetect? > > Not in Enumerable because each only iterates in one direction. (Ok, you > could go through it an output the last but that would not work for > Enumerables that return infinite elements.) I see. Hmm... sometimes it seems like these are quite categorized as finely as they might be. T. -- ( o _ カラチ // trans. / \ transami@runbox.com I don't give a damn for a man that can only spell a word one way. -Mark Twain