From: Steven Jenkins <steven.jenkins@...>
Date: 2005-06-23T13:56:36+09:00
Subject: Re: Super-scalar Optimizations

Ara.T.Howard wrote:
>   do_something = lambda {|arg|
>     ... 15 lines of code
>     true
>   }
> 
>   do_something[arg] and (foo = bar) and loop{ do_something[arg] }
> 
> 
> pulling out little blocks of code that are re-used by can't be methods
> due to
> context senstive behaviour or because they are just too small is what
> lambda
> abstraction is for ;-)

OK, you got me thinking. I've built a Ruby extension to access a system
engineering database we use at work. The vendor provides a C API, which
I've wrapped with SWIG. SWIG is useful, but the generated Ruby methods
aren't very Ruby-like. So I've written a layer on top of the SWIG
methods. Most of the layer methods look like this:

  def framelist
    ret, list = CAPIitem_getframelist(self)
    check_result(ret)
    list
  end

Object#check_result is a common method that checks for an error
indication, finds what the last error was, and raises the corresponding
exception:

  def check_result(res)
    return unless res == Cradle::FALSE
    code, msg = CAPIlast_error()
    raise EXCEPTION[code], msg
  end

Is there any reason to prefer, or not, using a lambda for check_result?
The only downside I can see to the current implementation is that the
backtrace for all exceptions ends in check_result. You have to look at
the next level to see where the error actually occurred. (I think it's
almost the same with a lambda, but it doesn't report it's in another
method).

Ideas?

Steve