From: Jean-Hugues ROBERT <jean_hugues_robert@...>
Date: 2002-06-13T19:25:48+09:00
Subject: Re: procs and blocks

Hello,

For what its worth: Handling both Proc & block parameters

def a( block = nil, &syntax_block )
   block = syntax_block if syntax_block
   # or block = syntax_block unless block
   block.call()
)

b = Proc.new do print "hello" end
a b # Works with Proc
a do print "world" end # And block too

The main drawback is that optional parameters become mandatory when
one want to use Proc object instead of block:
def err( msg = "Err", b = nil, &sb )
   b = sb if sb
   b( msg)
end
a = Proc.new do |x| print x end
err do |x| print x end
err "Hello" do |x| print x end
err "Hello", a
err( , a) # Not in Ruby syntax...

Yours,

Jean-Hugues

At 03:10 13/06/2002 +0900, you wrote:
>On Thu, Jun 13, 2002 at 02:40:01AM +0900, Evan Martin wrote:
> > latter sets $cb to a proc that wraps a block.  Or are a proc and a block
> > the same thing?
>
>Someone can probably give you a more thorough answer, but my understanding of
>it is that they are not the same thing.  However, for your purposes (when you
>are storing a callback) you can really only use a proc.
>
>The way I understand it is that a block is sort of a iconoclastic element of
>ruby in that it really isn't an object, and is only sort of an argument to
>whatever function it is given to.  This is for efficiency reasons, which makes
>sense considering that the main method of iterating over anything in ruby 
>is to
>use a block.  So it is much faster to use a combination of a block with yield
>for your basic iterators.  However, I don't think you can store a block by
>itself, you have to wrap a proc object around it.  I believe that all proc
>objects (created the normal way) store blocks.  So a block is just a proc
>that can be used directly without the overhead of creation, calling, etc.
>
>Also, for two of your solutions, the main difference for your purposes as far
>as I can see is that you get different failure modes:  (code not reproduced
>exactly, sorry)
>
>given
>def a(&p)
>     $cb = p
>end
>
>def b
>     $cb = Proc.new
>end
>
>irb(main):009:0> a      # nil is silently stored to $cb:
>nil
>irb(main):032:0> $cb
>nil
>irb(main):033:0> b
>ArgumentError: tried to create Proc object without a block
>     from (irb):29:in `new'
>     from (irb):29:in `b'
>     from (irb):33
>
>It seems that for a formal proc parameter there is a default value of nil,
>resulting in a reference to nil rather than the ArgumentError one might expect
>when it isn't given.
>
>Thinking about it, you might simply be better off for the purpose of callbacks
>taking the callback function as a normal argument; this way you can not 
>specify
>a default of nil if you don't want that, or you could give your own default.
>
>def a(p)
>     $cb = p
>end
>
>a(lambda do |arg| p arg.inspect end)
>
>hope this helps
>-kyle
>
>--
>http://mas.cs.umass.edu/~rawlins
>--
>There is no friend
>anywhere.

-------------------------------------------------------------------------
Web:  http://hdl.handle.net/1030.37/1.1
Phone: +33 (0) 4 92 27 74 17