On 1/21/10 8:09 PM, Charles Oliver Nutter wrote:
> It also seems very confusing to me that a method would show up in
> method lists, but respond_to? would produce false. I think this should
> always be true:
> 
> assert obj.respond_to? X if obj.methods.include X

I disagree. The reason being proxy objects:

  class Foo
    def foo
    end
  end

  class FooProxy
    def initialize(foo)
      @foo = foo
    end

    def something
      # Proxy-specific method
    end

    def method_missing(*args, &block)
      @foo.__send__(*args, &block)
    end

    def respond_to?(name, include_private = false)
      self.respond_to?(name, include_private) ||
        @foo.respond_to?(name, include_private)
    end
  end

foo_proxy.methods.include?(:foo) is false but can clearly respond to the foo method.


> * Hongli's suggested fork_supported?, though that pollutes some
> namespace for every such method we want to check

Can you special-case fork and always return false for respond_to?(:fork)?


> * Provide another mechanism for querying specific features, like
> Platform.support? :fork

How is this better than calling the method and catching NotImplementedError? Your
check method, although returning a boolean, still calls the method under the hood.
This makes #support? an expensive call which is something I wanted to avoid with
#fork_supported?.