"David A. Black" <dblack / wobblini.net> schrieb im Newsbeitrag
news:Pine.LNX.4.44.0407060841010.12255-100000 / wobblini...
> Hi --
>
> On Wed, 7 Jul 2004, Robert Klemme wrote:
>
> >
> > "David A. Black" <dblack / wobblini.net> schrieb im Newsbeitrag
> > news:Pine.LNX.4.44.0407060654550.23516-100000 / wobblini...
> > > Hi --
> > >
> > > On Tue, 6 Jul 2004, Robert Klemme wrote:
> > >
> > > > True.  The approach is betters suited to a method implementation:
> > > >
> > > > module Enumerable
> > > >   def index_2(obj=nil, &b)
> > > >     b = lambda {|x| obj == x} unless b
> > > >     inject(0) {|i,el| return i if b.call(el); i+1}
> > > >     nil
> > > >   end
> > > > end
> > >
> > > I agree.  My version, for what it's worth, was:
> > >
> > >   module Enumerable
> > >     def b_index
> > >       each_with_index {|e,i| return i if yield(e) }
> > >       nil
> > >     end
> > >   end
> > >
> > > I decided to make it orthogonal to #index, rather than a superset of
> > > it, on the theory that it would be good to avoid making it legal to
> > > give both an argument and a block.
> >
> > Might be best to just enhance #index with the block variant.
>
> What stumped me was: given this:
>
>   ary.index(x) {|e| <condition> }
>
> which behavior would you expect?  Or would it raise an exception?  I
> couldn't decide which would be best, which is what led me to a new
> method.

#index simply returns nil.

>  I can't remember whether there are any methods that protest
> if you give an argument and a block....  I have a memory that there
> are one or two, but I'm not sure what they are.

Well, what implication would that have?  Do you mean to say it's not
common in Ruby to have methods that either accept a block or an argument?

Regards

    robert