From: Alexander Schofield <pcs3@...>
Date: 2002-01-18T12:02:05+09:00
Subject: Re: Proc.class vs yield

Sorry if I'm resurrecting an old thread here, but I've been away for a
while.

> Because this whole yield thing isn't required, but it's there. Because
> people like it. But then there is this 'only one' restriction which,
> please excuse the expression, seems totally brain dead to me.

I'm not sure what you mean by restriction.  It's true that the yield
syntax isn't necessary and we could just pass Proc objects around as
named arguments as in smalltalk.  But for many cases it adds a lot of
visual distinction.  In that test block, action block method you
mentioned couldn't you use a named argument for the test, and the yield
construct for the action?

> I really do vote for having the compiler automatically handle the
> proc conversion for you.

Just to be certain, is this syntax construct what you are looking for? 
In this case the '&' makes a Proc object function like a block supplied
at the end of the method, different from when it used in a parameter
list.

irb(main):001:0> p = proc {puts 'from proc'}
#<Proc:0xbe92c0>
irb(main):002:0> def meth
irb(main):003:1> yield
irb(main):004:1> end
nil
irb(main):005:0> meth &p
from proc
nil
(sorry if someone already mentioned this)

The nice thing about this is that if you had a method with an (*args)
parameter list, *args wouldn't swallow the &p and the yield would still
work.  Also, yield is often convenient when you need a little more
flexibility with named arguments:

def meth
    yield 1, 2
    yield 3
end

p = proc {|one, two, three| p one, two, three}
meth &p  #this will work (three is nil, then two and three are nil)
#but this next part will fail.
p.call 1, 2
p.call 3
#yield's also convenient when you give what would ordinarily be too many
arguments

regards,
Alexander Schofield