[ruby-core:27664] Re: [Bug #2619] Proposed method: Process.fork_supported?

On Thu, Jan 21, 2010 at 12:49 PM, Vladimir Sizikov <[e-mail]> wrote:
> I should probably also add that this is close to impossible to
> implement on JRuby (and I assume on IronRuby too, and maybe some
> others). In case of JRuby, we build once and then the resulting
> product can be used on various platforms, so those platform specific
> things are queried at runtime. In some cases we just invoke a native
> functions via FFI at runtime and only then would see
> NotImplementedError out of those calls. So, basically, untill the
> method is executed, we can't really know whether it is supported or
> not on some platforms.
>
> So, this new behavior is not "portable" in a sense that it won't work
> on all 1.9.2-compatible implementations, which would only add to
> confusion.

I agree. Unless we dynamically go through all "potentially
unimplemented" methods in the system and attach ahead-of-time tests to
them, JRuby will not be able to support this. There is no
system-specific compile time for JRuby, and as Vladimir mentions, we
can't know what system we're going to run on until we start running.

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

For handling this fork case (and similar cases), there are other solutions:

* Hongli's suggested fork_supported?, though that pollutes some
namespace for every such method we want to check
* Just don't implement the method if it's not implemented. This
doesn't help cases like in JRuby, where we may not know until runtime
if we can support a method or not.
* Provide another mechanism for querying specific features, like
Platform.support? :fork

As Ruby moves forward, it would be helpful if everyone remembered that
MRI is not the only implementation anymore, and changes impact all the
implementations in different ways.

- Charlie