On Sat, 18 Jan 2003 dblack / candle.superlink.net wrote:

> But then it's unnecessary.  respond_to? returning false is already the
> equivalent of the NACK scenario.  The gist of the NACK idea is to have a way
> to do it without respond_to? -- that is, to have the method call itself
> return something which means the object didn't respond.

i finally got this.  too much of the coffee-beer-coffee-beer cycle...

> I was thinking mainly of String#intern:

that's at least the second time i've forgotten about that method.  i've never
really understood why there cannot be

  class Symbol
    def initialize str
      ...
    end
  end

which i would NOT forget about...

i looked into parse.c (rb_intern) and it's certainly looks possible...

>   $ cat sym.rb
>   print "String: "
>   sy = gets.chomp.intern
>   puts "Corresponding symbol is #{sy}, which is a #{sy.class}"
>
>   $ ruby sym.rb
>   String: blah
>   Corresponding symbol is blah, which is a Symbol

you are absolutely correct.  this DOES install a new symbol in the table at
runtime.  again, why no Symbol#new str i wonder?

> In this case it's not a matter of hiding or ignoring exceptions, but
> of implementing a different (non-exception-related) way of handling
> the no-method situation.
>
> For me there are two problems with the exception-wrapping idiom:
> speed, and the absence of an exception which precisely and uniquely
> corresponds to "this object did not respond to that message."
> NameError can represent a case where the method got called but,
> itself, tried to call a non-existent method on an object.

good point.  but wouldn't simply returning NACK from method missing accomplish
this?  (see my other post)


-a

-- 

 ====================================
 | Ara Howard
 | NOAA Forecast Systems Laboratory
 | Information and Technology Services
 | Data Systems Group
 | R/FST 325 Broadway
 | Boulder, CO 80305-3328
 | Email: ahoward / fsl.noaa.gov
 | Phone:  303-497-7238
 | Fax:    303-497-7259
 ====================================