Suppose you write some RPC interface, and the incoming data structure tells you what method to call on a certain object. In order to give the appropriate error message when it's not possible to call the method, you need to check if the method exists prior to calling it.

You can't generally just try it, and catch a MethodDoesNotExist exception if it goes wrong, because that might be an internal error from within the called method too. And it's nice for the user to distinguish the "method does not exist" and "internal error while calling method" errors.

Hm. In my opinion that is wrong.

If I were using a module via RPC, I would want it to act exactly the same as if I were using it locally. If using it locally would raise an exception, I would want the same exception raised when calling it remotely with the same arguments. If it returns error codes, then that's what I want to receive. In this way, not only can I test locally; the local/remote state can be transparent to the calling code.

The last thing I want to have to do, is start checking whether the interface layer has decided to "helpfully" turn the actual result of the remote call into some diagnostic, and then have look up what that diagnostic means in another set of documentation. Especially as the diagnostic would inevitably be couched in generic terms rather specific to the actual module being called. And then code special cases to deal with the same problem dependant upon whether it is local or remote.

But the real downside of the non-distinction between subs and methods is the fact that importing utility subs from modules makes them available as methods, and even if you don't care, somebody inheriting from your class wonders what's up with those weird method calls.

That's an education thing. Don't export subroutines from an OO package.

If you have to have a module that both does OO, and exports subs, put the subs in a sub package name-space and export them from there.

But better still, don't export "utility subs". Write them as class methods, and have them expect (and check for) the class parameter.

I've still yet to see a use for introspection--beyond a simple ref--that isn't just an "in vogue", but bad, solution to problems, that should be addressed by better coding practices.