[ruby-talk:01333] Re: Bug in Kernel.open (I think)

[e-mail] (Yukihiro Matsumoto) writes:

> In message "[ruby-talk:01318] Bug in Kernel.open (I think)"
>     on 00/02/12, Dave Thomas <[e-mail]> writes:
> 
> |You recently changed Kernel.open so it would take a block in the pipe
> |form. Unfortunately, I think now it _has_ to take a block:
> 
>   * unavoidable conditional
> 
>     By new behavior, nil check in the block is must.  It's not as easy
>     as it should be, I think.  For example, `fork' uses block to
>     execute under child process.
> 
>       fork { p "in child" }

I can see a certain symmetry here, although it's harder to
document. The idea that

   open(..) { |f| ... }

runs the block with 'f' set to the return value from open works across 
all the versions of open with the new behavior. If you special case
it, then the explanation gets longer and more confusing. So, the
principle of least surprise would argue for the new behavior.

Alternatively, I can also see the argument that says we should keep
the old behavior.

Maybe we should revert for now, until you invent the indexed yield:

   yield[n] p1,p2...

yields to the 'n'th block.

Now there's a construct with the potential for some fun semantics!

Regards

Dave