From: Richard Zidlicky <rz@...68k.org>
Date: 2003-07-20T18:35:18+09:00
Subject: Re: [Patch] FTP.new with block

On Sun, Jul 20, 2003 at 03:06:13AM +0900, Dave Thomas wrote:
> Mathieu Bouchard wrote:
> 
> >On Sat, 19 Jul 2003, ts wrote:
> >
> >>>>>>>"G" == Gavin Sinclair <gsinclair@soyabean.com.au> writes:
> >>
> >>G> FTP.new and FTP.open are like their File counterparts: they accept a
> >>G> block, pass in the ftp object, and ensure the FTP connection is closed
> >>G> at the end of (or premature exit from) the block.
> >>Why all persons think that File::new can take a block ?
> >
> >
> >That's psychological: when people have a lot of things to learn, they
> >(carefully or not) forget the pieces that they can reinvent on the fly.
> 
> 
> Perhaps it's an argument for having File.new take a block too...
> 

something more systematic is needed. So far only 2 widely used 
classes appear to evaluate blocks passed to new: Proc and Tk.
Furthermore Tk is somehwat confusing for the beginner because
it uses instance_eval or something completely different to eval
the block.

Currently this is a mess because many "new" methods will *silently*
ignore the block, also the inability to tell easilly if a block
is evaluated by yield, instance_eval or something completely
different is not so helpfull. To make things worse it is not
clear what, if anything is returned when a block is taken.

How to get it consistent? Leave the 2 widely used exceptions
to the rule (no block arg for new) some time to phase out and
use either a clear naming convention (eg new_wb instead of new)
or some enhanced syntax sugar to make sure blocks don't get
ignored/misinterpreted without signaling an error.

# extend Object with method new_wb requiring a block
class Object
  def new_wb(*args)
    if block_given?
      res=new(*args)
      yield res
    else
      raise SyntaxError, "new_wb method requires a block"
    end
    return res
  end
end

Richard