Hi --

On Mon, 9 Jul 2007, Yukihiro Matsumoto wrote:

> Hi,
>
> In message "Re: Yield should be renamed call_block"
>    on Mon, 9 Jul 2007 19:17:13 +0900, dblack / wobblini.net writes:
>
> |> I am not going to rename it.  But in far future (3.0? maybe), the
> |> keyword will be removed from the language, and you will access blocks
> |> via block arguments of methods.
> |
> |I'm curious what the rationale is for that.  Also, will the block
> |syntax be removed, in favor of Proc arguments?
>
> The code
>
>  def ntimes(n)
>    n.times do
>      yield
>    end
>  end
>
> would go like this
>
>  def ntimes(n, &b)
>    n.times do
>      b.yield
>    end
>  end
>
> Rationals are:
>
>  * you can detect methods that don't take blocks, that
>    currently ignored silently.
>  * we can make yield sementics bit simpler.
>
> The former is more prefereable.

If this ends up happening, I would (reluctantly) suggest getting rid
of "yield", and just use call.  b.yield, as others have pointed out,
doesn't really work semantically: the function isn't yielding, it's
being yielded *to*.  Maybe:

   yield >> b

or something.

The point about detecting blocks is interesting, though if a block is
still optional, you might end up testing at the calling end and in the
method, which seems like a lot of testing.  Or is there another
permutation for required block vs. optional block?


David

-- 
* Books:
   RAILS ROUTING (new! http://www.awprofessional.com/title/0321509242)
   RUBY FOR RAILS (http://www.manning.com/black)
* Ruby/Rails training
     & consulting:  Ruby Power and Light, LLC (http://www.rubypal.com)