Re^3: In praise of Perl's object system.

That's what documentation is for.

Assuming a perfect world, in which you know which files to search in for documentation, I'd agree.

Having worked with XML::LibXML I found the documentation to be scattered over so many different files (due to a steep inheritance hierarchy) that consulting the documentation was often more work than writing a small example, and using introspection.

Can you suggest one realistic scenario where there is a need to decide between a subroutine and a method at runtime?

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.

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.

This is a real problem, and has happened to the DBIx::Class users and developers. Their "solution" was namespace::autoclean, but it's really just a workaround, not a solution.

Perl 6 - links to (nearly) everything that is Perl 6.

Comment on Re^3: In praise of Perl's object system.

Replies are listed 'Best First'.
Re^4: In praise of Perl's object system. by BrowserUk (Patriarch) on Oct 01, 2010 at 11:45 UTC
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. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. RIP an inspiration; A true Folk's Guy	[reply]
Re^5: In praise of Perl's object system. by moritz (Cardinal) on Oct 01, 2010 at 11:53 UTC
Hm. In my opinion that is wrong. Your opinion doesn't mean it's not a valid use case. That's an education thing. Don't export subroutines from an OO package. I was writing about importing, not exporting. I don't always have control of the API of modules I use. Perl 6 - links to (nearly) everything that is Perl 6.	[reply]
Re^6: In praise of Perl's object system. by BrowserUk (Patriarch) on Oct 01, 2010 at 12:00 UTC
Your opinion doesn't mean it's not a valid use case. It's not the use case that's invalid, just the solution. I was writing about importing, not exporting. I don't always have control of the API of modules I use. Doesn't `use Exporting::Module ();` plus `Exporting::Module::utility_sub( ... );` address that?	[reply] [d/l] [select]
Re^7: In praise of Perl's object system. by moritz (Cardinal) on Oct 01, 2010 at 12:03 UTC
Re^8: In praise of Perl's object system. (OO namespaces) by tye (Sage) on Oct 01, 2010 at 18:57 UTC
Re^8: In praise of Perl's object system. by BrowserUk (Patriarch) on Oct 01, 2010 at 12:09 UTC
Some notes below your chosen depth have not been shown here
Re^8: In praise of Perl's object system. by ikegami (Patriarch) on Oct 01, 2010 at 19:02 UTC


Come for the quick hacks, stay for the epiphanies.
	PerlMonks