[ruby-core:27742] Re: [Feature #2619] Proposed method: Process.fork_supported?

On Fri, Jan 22, 2010 at 9:06 PM, Charles Oliver Nutter
<[e-mail]> wrote:
> I would not argue against a feature just because of complexity,
> however. In this case, it seems that users will still need to expect
> that different platforms might respond_to? a method but still raise
> errors at runtime. I don't feel that the added complexity (present but
> less in 1.9, more in JRuby/IronRuby) is worth it.

I want to make it clear I'm not just trying to be difficult. Currently
I don't see a simple way for us to observe the new respond_to?
behavior. We know for a fact there are many methods which we bind
regardless of platform because we can't know without calling them if
they're available. If we can't do it simply in JRuby, we won't do
it...and that will mean that the new respond_to? behavior is
ultimately unreliable across implementations. If it's unreliable, it's
no longer useful.

We are certainly open to suggestions on how to implement it. We would
also like to see a specification for how the behavior is supposed to
behave and which methods one might expect to exhibit the behavior.

A quick inspection of 1.9 shows the feature is not even consistent
there. The 'etc' module, for example, still returns nil for any
methods that are not available, and does not appear to respond_to? =>
false for any of them.

For the fork case, I think it best for us to not bind the method at
all. There's no good reason for us to bind it, knowing the JVM can't
fork, and so it will respond_to? => false for both 1.8 and 1.9 modes.
If there are other trivial cases, we will probably do the same. But I
don't see how we can guarantee that respond_to? => true will
accurately reflect that a method/function is available on the current
system, and for now we will not support that behavior. If the method
is bound, it will respond_to? => true on JRuby.

- Charlie