On Fri, 17 Jan 2003 dblack / candle.superlink.net wrote:

D> It can be done, but it's not a general solution, because there might
D> be methods that do exist and still return nil.  Thus a nil return
D> can't be treated as an unambiguous synonym for not responding.

why not add a new return value to Object::respond_to? ?

eg:

  case o.respond_to? :sym
    when true
      # o responds to this
    when false
      # o does not respond to this
    when nil
      # o does not acknowldedge this (NACK)
  end

i believe this would maintain backwards compatibility since old code would not
distinguish between false/nil returns from respond_to? but would allow new
code to have the concept of NACK without any new classes or globals required.

can someone give me a simple example of wanting a NACK though?  i think this
thread has ignored the original question of how to :

   if self.respond_to?(:ameth)
           if ameth
                   if not ameth.to_s.empty?
                           ...
                   end
           end
   end

which to *me* seems to read "if i respond to a symbol known at *compile time*
then eval ameth a couple of times, where ameth may be a method call or local
varibable but i don't really care which, and iff ameth returned anything other
than '' then do ..." or something pretty close to this.  this seems really
from the hip : assuming this is some pretty dynamic code, wouldn't you have
some idea, based on what is in ameth, what to do with it more strongly
correlated to reality than whether or not self responds to the compile time
symbol :ameth?  i think if the purpose of the above logic were explained and
answer may arise not involving NACK at all...

-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
 ====================================