3 ms·

Moose vs Mouse: OOP in Perl

30 points by zrail 17y ago

wazoox 17y ago
In my understanding Mouse is to become irrelevant someday, as Moose goes forward.
- zrail 17y ago
  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.
- msbarnett 17y ago
  From what I've heard the future lies with Squirrel, unless Moose manages to pull a rabbit out of its hat.
  - zrail 17y ago
    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.
- autarch 17y ago
  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.
jrockway 17y ago
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.)
- zrail 17y ago
  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 :))
  - jrockway 17y ago
    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.pl http://github.com/jrockway/app-persistent/blob/master/repl.p... And if you use MooseX::Runnable, it is automatic. (Just load with +Persistent.)
    - zrail 17y ago
      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.
rmk 17y ago
Moose was pretty difficult to grok, what with the variety of extensions that came with it. Anybody know a good Moose resource?
- zrail 17y ago
  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.pod http://search.cpan.org/~flora/Moose-1.03/lib/Moose/Cookbook....

30 points by zrail 17y ago

wazoox 17y ago

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

zrail 17y ago
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.
msbarnett 17y ago
From what I've heard the future lies with Squirrel, unless Moose manages to pull a rabbit out of its hat.
- zrail 17y ago
  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.
autarch 17y ago
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.

jrockway 17y ago

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.)

zrail 17y ago
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 :))
- jrockway 17y ago
  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.pl http://github.com/jrockway/app-persistent/blob/master/repl.p... And if you use MooseX::Runnable, it is automatic. (Just load with +Persistent.)
  - zrail 17y ago
    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.

rmk 17y ago

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

zrail 17y ago
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.pod http://search.cpan.org/~flora/Moose-1.03/lib/Moose/Cookbook....