From: Robert Klemme <bob.news@...>
Date: 2004-01-26T19:55:00+09:00
Subject: Blocks as Block / Proc parameters


"Mauricio Fern�ndez" <batsman.geo@yahoo.com> schrieb im Newsbeitrag
news:20040125140229.GA13890@student.ei.uni-stuttgart.de...
> On Sun, Jan 25, 2004 at 10:14:56PM +0900, Robert Klemme wrote:
> >
> > "Mauricio Fern�ndez" <batsman.geo@yahoo.com> schrieb im Newsbeitrag
> > news:20040124235621.GA7427@student.ei.uni-stuttgart.de...
> > > On Sun, Jan 25, 2004 at 05:04:58AM +0900, Robert Klemme wrote:
> > > > Cancel that.  This works:
> > > >
> > > > class Module
> > > >   def notify(sym)
> > > >     new_sym = "#{sym}_old".intern
> > > >     alias_method new_sym.to_s, sym.to_s
> > > >
> > > >     define_method sym do |*args|
> > >
> > > Isn't it a shame that you cannot propagate blocks with
define_method?
> >
> > Yeah, that's true.  I ran into it while figuring how to do it.
>
> What would you think about Kernel::block_given, returning a Proc
> corresponding to the block or nil?

I don't like it because it imposes the additional overhead of a proc
creation even for cases when you just want the boolean information.  How
about extending Proc to accept blocks like this:

proc {|foo, &bl|
  puts "foo=#{foo}"
  bl.call if bl
}

Or at least extend Proc#call to use blocks.  Currently this is what
happens:

irb(main):063:0> proc {|*args| p args; p block_given? ; yield }
..call(1,2,3) { puts "block!" }
[1, 2, 3]
false
LocalJumpError: no block given
        from (irb):63
        from (irb):63:in `call'
        from (irb):63
        from :0

Matz, this is not too big a change, is it?

Regards

    robert