Perl OO frameworks and program design - Moose and Conway's inside-out objects (Class::Std)

Question

This is more of a use-case type of question... but also generic enough to be more broadly applicable:

In short, I'm working on a module that's more or less a command-line wrapper; OO naturally. Without going into too many details (unless someone wants them), there isn't a crazy amount of complexity to the system, but it did feel natural to have three or four objects in this framework. Finally, it's an open source thing I'll put out there, rather than a module with a few developers in the same firm working on it.

First I implemented the OO using Class::Std, because Perl Best Practices (Conway, 2005) made a good argument for why to use inside-out objects. Full control over what attributes get accessed and so on, proper encapsulation, etc. Also his design is surprisingly simple and clever.

I liked it, but then noticed that no one really uses this; in fact it seems Conway himself doesn't really recommend this anymore?

So I moved to everyone's favorite, Moose. It's easy to use, although way way overkill feature-wise for what I want to do. The big, major downside is: it's got a slew of module dependencies that force users of my module to download them all. A minor downside is it's got way more functionality than I really need.

What are recommendations? Inconvenience fellow developers by forcing them to use a possibly-obsolete module, or force every user of the module to download Moose and all its dependencies?

Is there a third option for a proper Perl OO framework that's popular but neither of these two?

Answer 1

Well, there's Mouse, which is like Moose but without all the dependencies (and some of the features). It also starts up a bit faster. I haven't tried it myself, but it's generally well thought of.

Answer 2

To be perfectly fair, seeing virtually everything interesting these days in Perl world has Moose somewhere as a dependency, I don't see it being much a debt for other "fellow Perl developers".

Chances are they already have it installed as we speak!

Edit: Some statistics:

Moose is currently rated at 65th place on the "Most Depended on" modules list, Aliases top 100, with over 1637 packages depending on it. Thats almost as much as stuff like Time::HiRes , and more than DBI, and I don't think you're as likely to question depending on those would you?

Answer 3

The currently accepted "modern Perl OO framework" is Moose. I'd say make your users download it, or you can bundle it up with your modules in the installation using PAR::Packer.

Quoting from "But I can't use CPAN" (...because my users won't want to install things):

Assuming you're just handling your users a tarball, then Module::Install provides a solution - if you put your script into script/ and then do

install_script(glob 'script/*');
auto_install;

in your Makefile.PL, then not only will 'make install' put your script somewhere useful for you but 'make installdeps' will invoke cpan (or if present, cpanplus) to install all missing dependencies for you.

Answer 4

To add to the existing fine answers...

Some of what was recommended in PBP isn't bad advice, but Perl marches on. When it was written, inside-out objects were the new hotness. Now the Moose has absorbed all. There is MooseX::InsideOut which gives you the power of Moose with the total encapsulation of Class::Std, but unless you work with undisciplined programmers its really not necessary.

Those features of Moose you don't need now, you'll need them eventually. Even if you don't need all of them, with Moose you won't have to use and learn Yet Another OO System every time you need an interesting feature. And god forbid you need TWO features at the SAME TIME!