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

On Fri, Jan 22, 2010 at 1:25 PM, Yukihiro Matsumoto <[e-mail]> wrote:
> As far as I understand, he only said there are some cases whether the
> availability of a feature can only be known at runtime, not impossible
> to implement 1.9 behavior.  So I want to make your opinion clear.  You
> don't like the implementation complexity to implement 1.9 respond_to?
> behavior, or something else?

There would definitely be a lot of added complexity to implement this
behavior in JRuby, since we don't know until runtime for *most*
methods whether they'll be supported or not. We build once at release
time, and then the same binary is used on many different platforms.

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.

It also seems like JRuby could simply lease 1.8 behavior in place,
since users may have to rescue errors on all implementations anyway.
Have I misunderstood?

Perhaps you could describe what you think the new behavior is supposed
to be? I'm confused now:

Which of these are correct? (referring to the default respond_to?, not
custom ones)

A: respond_to? should return true iff a method is bound on an object's
class or superclasses (i.e. will not raise NoMethodError)
B: respond_to? should return true iff (A) and the method will never
raise NotImplementedError on any platform
C: respond_to? should return true iff (A) and the method will never
raise NotImplementedError on the current platform
D: respond_to? should return true iff (C) and the method will not
raise system-level "not implemented" errors (like ENOTIMPL or ENOSYS)

Case A is 1.8 behavior and easy to support. If it's there, true; if not, false.

Case B is also pretty easy; we'd have to flag methods we know we have
hardcoded to raise NotImplementedError, and respond_to? would check
that flag. It only works for methods that are never implemented on any
platform, however, which makes me wonder why they're there in the
first place.

Case C is hard; we would have to have special-cased code for each such
method to check at runtime if the current platform supports it, and
make a best guess from there. This logic would have to run for every
new process.

Case D is probably not possible without a very large amount of work
and special-casing at compile time or runtime for all platforms.

I'm also curious how this affects Windows behavior, since currently
MRI stubs out many methods to return nil on Windows (like all of 'etc'
library, for example). Should they raise NotImplementedError? Should
they return false for respond_to?.

- Charlie