From: dblack@...
Date: 2003-01-17T11:41:34+09:00
Subject: Re: quick: it responds, it evaluates, and is not empty

Hi --

On Fri, 17 Jan 2003, Gavin Sinclair wrote:

> On Friday, January 17, 2003, 12:35:32 PM, dblack wrote:
>
> > I continue to dislike the repetition of the
>
> >   if obj.respond_to?(:meth) then obj.meth ...
>
> > thing, although I don't know how to circumvent it efficiently and
> > effectively.
>
>    begin
>      obj.meth
>    rescue NameError
>      "Well, I guess we're stuffed, then."
>    end
>
> I remember you doing this in dbdbd, and I thought it was quite
> elegant.

I do actually like that construct -- it's just kind of (comparatively)
slow.  Maybe my impression of its slowness is exaggerated by the fact
that my first use of it was in an XML-processing loop, and the
slow-down was quite noticeable.

I've actually been thinking about whether one could plausibly
implement a sort of "NACK" response (i.e., lack of response) from an
object, which would be neither nil nor false nor an exception, but
which would happen in the course of the method being called:

  case self.some_meth
    when /y/ ...
    when /n/ ...
    when nil ...
    when nack ...
  end

> I used it once to handle a nil argument in place of
> something that responds to :to_h
>
>   hash =
>     begin
>       arg.to_h
>     rescue NameError
>       {}
>     end
>
>
> I wanted to do
>
>   hash = arg.to_h rescue {}
>
> but that doesn't work.

It does in 1.8.0preview1:

  $ ruby -ve 'h = "".to_h rescue {}; p h'
  ruby 1.8.0 (2002-12-24) [i686-linux]
  {}

which is cool.


David

-- 
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web:  http://pirate.shu.edu/~blackdav