Hi -- On Sat, 18 Jan 2003, ahoward wrote: > 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. This is different, though, from having the (attempted) call to the method itself return NACK. Also, I'm not sure what the difference is between your false and nil cases. > 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 No, respond_to?(:meth) doesn't pertain to local variables. Also, symbols aren't specifically compile-time things; they can be dynamically generated. And respond_to? can take a String too. The idea of NACK would be to have a way to accomplish both the test for method existence, and the actual call of the method, in one expression, instead of having to break them out as in Tom's example. David -- David Alan Black home: dblack / candle.superlink.net work: blackdav / shu.edu Web: http://pirate.shu.edu/~blackdav