From: "David A. Black" <dblack@...>
Date: 2004-07-08T00:17:01+09:00
Subject: Re: Array::index and rindex operator

Hi --

On Wed, 7 Jul 2004, George Ogata wrote:

> "David A. Black" <dblack@wobblini.net> writes:
> 
> >> 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!" }
> 
> Well, one could also counter-argue that in the useless-block cases
> it's not ambiguous, though I think ideally, ruby should still
> complain.  I guess it doesn't due to a combination of ruby's dynamic
> nature (it can't determine for itself whether or not a block might be
> needed at compile time, and it's inefficient to check it at runtime),
> and ruby's "no declarations" philosophy (i.e., no declaring "I take
> blocks" in the method definition).  Perhaps also because a useless
> block isn't an oft-made mistake.

I'd rather not have a warning in the general case (i.e., imposed by
the interpreter rather than by the method's own logic).  One might
have something like:

  def x
    @cached ||= yield * 10
  end

where the yielding happens conditionally.  (Classically non-wonderful
example, but still :-)

> As for the "left-to-right" view, there's no precedence for this being
> silently ignored in the presence of ambiguity, is there?

I don't think any existing methods do this; I'm really just
speculating about whether or not it would make sense to write a method
that way.  I think it would, at an abstract level, but having the
method intervene if one calls it ambiguously also makes sense, perhaps
more sense at the practical level.  


David

-- 
David A. Black
dblack@wobblini.net