Moose, Mouse, Moo what next 'M'
My step into what I wood call the world of Moose was actually job related a few years ago and have been happy with it ever since.
One thing in the community I have seen it the rise of other flavors of 'postmodern object system' perl namely the first 'Mouse' and the more recent 'Moo'. Will 'M' will be next? I had some time after bashing in walls and laying wire so I had a look at them.
Both I guess try to solve the same problem mainly the over head of Moose. Mouse drops some parts of moose and redoes others and tries to retain most of Moose's syntax, Moo takes a use only what you need approach so is a little more basic but is much more compatible with Moose.
Both state that they are useful for 'CGI' command line and other simple implementations. To me this begs the question why would you even choose OO design for the above three situations??
If you need to write some thing that is fast I think over head from any add on OO system is not what you want.
Yes accessors are great but you can easily write those up in only a few lines of code as demonstrated here by David Farrell at Perl Tricks. You do not even need this if you are lucky and can use a later version of perl they are built in Attributes.
Well my humble opinion is when you start to use just bit-and pieces of OO in a system you always start out with the best intentions but in the end you will be painting yourself into a corner.
My Orignal (anyone got the joke with this name yet?) is an example of that. It started out as a simple way to stop me from having to type
my thingy{
my $self = shift;
if (@_) {
$self->{thingy} = shift;
return 1;
}
return $self->{thingy};
};
50 or 60 times over and like David's started out as just a few lines of code. If at the time I was not stuck in perl 5.6 I would of used perl's buitl in Attributes instead. As I relate in this post someone wanted arrays, then validation then ordered hashes and it quickly grew a little out of hand. The part I put on CPAN was the most useful as what was in use became quite behemoth (until we swapped over to Moose)
In the end, if I had to choose, I guess Moo might be the better with its 'pay as you go' approach than Mouse and its 'We do things different but the same' approach.
I think my point is valid though why go down that road in the first place, if you need speed OO of any form is not the way to go.
But then again this is just my silly opinion late on a Saturday night or maybe I am just tired from renovating the kitchen.
M is old news.
Also, the "attributes" discussed in perldoc attributes are an entirely different thing to the "attributes" defined by Moose/Mouse/Moo. Same word used for two unrelated purposes.
The former "attributes" are similar to "decorators" in Python; the latter "attributes" are what might be called "class members" in C++/Java, or "properties" in PHP.
At lest Mo is a little newer. Trust Mr Trout for coming up with 'M'. I guess 'Q' must be next:)
There's no reason OO is less appropriate for CGI or command line programs, especially if they share components with a larger system.
The only real concern is if the overhead is worth it. And for Moo and Mouse, you won't even notice their load time. The accessors they create will be as fast as or faster than anything you write yourself.
Moo also gives you get the benefit of being able to cleanly inter-operate with a larger system. So if you have something like a Catalyst driven web site, it can share components with utility scripts, and they can still be fast.