Hi --

On Tue, 10 Jul 2007, Bharat Ruparel wrote:

>> I've always thought of the yield mechanism as one of the most
>> strikingly elegant and expressive things in Ruby.  (More subjective
>> judgment :-)  I'm actually very surprised to hear that it's likely to
>> disappear, or change considerably.
>>
>
> I think that Matz is on to something again!
> The more I think of yeild as a method on an object, less it bothers me.

It would bother me if the object were one where the concept of
"yielding" didn't apply, like a Proc :-)

I always think of these things at least in part in relation to
teaching (or writing about) Ruby.  Explaining the concept of a method
yielding control to an anonymous function is actually quite easy to
explain, with a diagram or two.

Explaining block.yield, though, would be impossible.  What does it
yield?  Nothing.  What does it yield *to*?  It doesn't.  It's just a
word that used to have a different meaning and is now a synonym for
"call", even though "yield" and "call" have almost opposite semantics.

So... I'd rather not have it :-)  But I think the more interesting
thing is the question of what Matz is trying to address, namely the
business of being able to tell whether a method requires a block.  I
imagine that by 3.0 we'll have a wonderful and elegant way to do
exactly that.


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)