From: "David A. Black" <dblack@...>
Date: 2004-07-07T21:46:20+09:00
Subject: Re: Array::index and rindex operator

Hi --

On Wed, 7 Jul 2004, George Ogata wrote:

> ts <decoux@moulon.inra.fr> writes:
> 
> >>>>>> "D" == David A Black <dblack@wobblini.net> writes:
> >
> > D> I still have this nagging memory of a method that raises an exception
> > D> when given both, but I can't pin it down.
> >
> > svg% ruby -e 'Hash.new("aa") {}'
> > -e:1:in `initialize': wrong number of arguments (ArgumentError)
> >         from -e:1:in `new'
> >         from -e:1
> > svg% 
> >
> > svg% ruby -e 'instance_eval("aa") {} '
> > -e:1:in `instance_eval': wrong number of arguments (1 for 0) (ArgumentError)
> >         from -e:1
> 
> Interestingly:
> 
> g@crash:~$ ruby -e 'Array.new(1, 1){1}'
> -e:1: warning: block supersedes default value argument
> 
> But to answer David( Black)'s concern, I think the only sane choice is
> to raise an exception when both are given.  It's ambiguous, so it's an
> error, right?

It's an interesting problem, since the existence of #block_given?
suggests that branching on the presence/absence of a block is legit,
though these instances show that for this purpose it can be rather
messy.  

I tend to favor the exception approach, though one could also argue
for a left-to-right logic: if a method needs an argument xor a block,
then once it gets an argument, let it be satisfied and ignore the
block (which is also a legit and indeed default action).  One would
then have to be careful not to have stray useless blocks, but that's
already the case; one already could, but presumably would not, do
this:

  /blah/.match(str) { puts "useless block!" }


David

-- 
David A. Black
dblack@wobblini.net