From: Ryan Leavengood <mrcode@...>
Date: 2005-06-29T05:49:45+09:00
Subject: Re: yield does not take a block

Eric Mahurin said:
>
> I tend to agree that the yield should be made consistent with
> block.call such that yield would basically be just an alias for
> block.call (where block is the block given to the current
> method).  I think any keyword that can reasonably be made to
> look like a method call, should.  Makes the syntax more
> consistent.  If you were starting over, I'd even suggest things
> like if/while to be like (or actually) method calls.

Though I understand matz's seeing the yielding of a block as a bad kind of
strangeness, I do think consistency is good. If yield and block.call are
different in any way that could be confusing, especially to all these new
Ruby users we've been getting lately. So I agree with Eric here.

I still would like to see a case where a block is yielded, and just how
that would be used. Sounds like potentially confusing code to me.

I also like the idea of if and while being methods, just as long as the
current syntax sugar is maintained.

> Personally, I don't think having yield as a keyword really adds
> that much value to the language.  The only advantages I see
> over explicitly having a &block arg and using block.call are a)
> it looks like smalltalk, and b) rdoc parses it better.  I think
> showing the &block on the def line makes the method interface
> clearer up front.  I don't use yield at all and haven't missed
> it.

I like yield as a keyword, and I think the only reason to use &block is
when you want to save the given block or do some other manipulation on it
(ask for its arity, etc.) It is a lot of extra typing to use an &block
parameter than just calling yield, especially if all you want to do is
yield a value. Conceptually I think the idea of 'yield'ing control to a
block is nice (though I suppose the idea of 'call'ing a block is just as
nice.) But I still don't think yield should be tossed (not that matz ever
would.)

Ryan