From: Gavin Sinclair <gsinclair@...>
Date: 2003-04-28T18:06:36+09:00
Subject: Re: block.call vs. yield

On Sunday, April 27, 2003, 1:13:40 AM, dblack wrote:

> I think that if the semantics of yield are to be generalized, they
> should be thought of as something other than the semantics of yield.
> It seems to me that the situation is somewhat like this:

>      type 1 semantics                     type 2 semantics
>    _____________________                 ___________________
>       |         |                          |              |
>       |         |                          |              |
>    methods    Proc#call                  yield        Proc#whatever

> in which case, yield and Proc#whatever share semantics, but there's no
> reason (except "historical reasons") to define them as "yield
> semantics".


The method name :yield was immediately intuitive to me, as was the
concept of "yield semantics".  One thing every Ruby programmer must
learn fairly early is the special treatment of arguments to "yield".

So yes, the only reason for the name is "historical reasons", but I
can't imagine a better name appearing.

If you want to take a step back and look for a unifying concept, which
I applaud, then I think the only choice is to abolish "yield
semantics".  The splat (*) operator allows you to achieve the same
result anyway - when you want to.

  hash.each do |o|
    # Array === o
  end

is annoying to some people.  They would rather have an error (wrong
number of parameters) than an unexpected value being assigned to the
parameter, and I sympathise.  After all...

  hash.each do |*o|
    # Array === o
  end

applies, so why not force intentions to be explicit?

I'm happy to keep "yield" the way it is.

Gavin