Moose vs Mouse: OOP in Perl | Hacker News Reader

Moose vs Mouse: OOP in Perl

bugsplat.info

30 pointszrail12 comments

Instead of resorting to hacks like Mouse, he should have just made his app persistent with App::Persistent. The client you use to connect to your persistent app starts up faster than perl.

Client/server works for xmms, firefox, emacs, ..., so why not you? Using a few extra megs of RAM is well worth not having to use Mouse.

(And oh yeah, if you have a laptop, an SSD is essential. Although much of immutable Moose startup time is actually CPU time, there is a pretty good disk component too. An SSD also lets you do clever things like cryopid-ing your scripts to achieve an effect like precompilation. Cryopid is not faster than App::Persistent, though.)

I certainly could have made it persistent but then I'd be adding significant complexity to a little run-and-done single-file data processing app. I mean, even before changing to Mouse the thing took only a few seconds to start up. Now it's less than half a second.

(Also, SSDs cost money :))

The "just rewrite your app to use a different object system" doesn't scale very well, but App::Persistent has a constant per-app overhead -- deciding what code to run in the server, and deciding what code to run per-client. (It's not automatic because the "omg magic" is what made pperl unusable.)

The persistent version of Devel::REPL, for example, is just a few lines of code:

http://github.com/jrockway/app-persistent/blob/master/repl.p...

And if you use MooseX::Runnable, it is automatic. (Just load with +Persistent.)

It wasn't a different object system, though. At the level I'm using Moose, Mouse was completely drop-in. I understand your point, but scaling isn't really a goal. I just wanted the script to run faster than it was.

I'm planning on building some persistent stuff at work and I'll definitely give App::Persistent a closer look when the time comes, but for a little script it's sort of overkill.

Why even use objects, then? Why not just use a hashref with key/value pairs? That's like 8 percent faster, and definitely not overkill!

In my understanding Mouse is to become irrelevant someday, as Moose goes forward.

That's the long-term goal, but to make that happen is pretty hard.

One possibility is implementing some sort of XS for all Moose core features, and using XS to implement Moose-based classes (Mouse already does this).

Another project which has been worked on, but has somewhat stalled, is a Moose "compiler" which would generate .pmc files for your classes. Unless you used the meta-model at runtime (most code doesn't), you'd never even need to load Moose.

Patches welcome, of course. If anyone's interested in these projects, join us at irc://irc.perl.org/#moose to discuss then.

Yes, I'm sure it is, just as Moose will become irrelevant when perl 6 becomes widespread. However, right now it's pretty handy if you have something where startup time matters and you don't mind giving up some of the deeper features of Moose.

From what I've heard the future lies with Squirrel, unless Moose manages to pull a rabbit out of its hat.

Squirrel is actually deprecated in favor of Any::Moose. They basically do the same thing except Any::Moose decides to use Mouse or Moose once, where as Squirrel will attempt to do it every time it's imported.

Moose was pretty difficult to grok, what with the variety of extensions that came with it. Anybody know a good Moose resource?

Working through a few examples helped me quite a bit. I think the Moose::Cookbook[1] is pretty descent.

[1]: http://search.cpan.org/~flora/Moose-1.03/lib/Moose/Cookbook....

Reply on news.ycombinator.com