This is the design document for the Mo module.
It is intended to help people understand the thinking behind Mo.
Like Mo, this document is a work in progress. Nothing here is in stone. Everything is up for discussion. This document just explains the current understanding, so you'll know where to start.
Mo has the following design goals. These goals are all important and have to be balanced against each other.
This includes at least the following. The current implementation contains a bit more than this, but that is due to the other design goals.
Mo should provide a mechanism for inheritance. At least single inheritance.
Mo needs to provide a new() object constructor. It should take a set of name/value pairs and return a new object reference, blessed into the class' package name.
new()
Mo needs to provide a way to declare attribute accessing methods. They need to be able to set and get values.
Mo only adds features if they are considered very desirable and can be implemented in a very small amount of code.
Mo wants to be the first module that Perl programmers reach for when they need simple OO. To that end, it needs to be extremely useful and support common idioms, even if they are not strictly minimal.
Mo should be about as fast as if you rolled your own OO. It should be fast at both startup (compile) time and at run time. It should especially strive to have fast accessors. Speed optimizations should be simple and minimal.
There may be situations where you want to inline Mo into your code, For this reason, Mo will try to be in one minimal pure Perl file, with no comments or documentation.
Moose has become the accepted style of OO in perl. Mo will attempt to not do the things it does in an incompatible style to the Moose family.
Moose
This is not to say that all Mo code can be switched to Moo, or vice versa. This is to say that you should be able to find a style of coding using the full capabilities of Mo, that you can switch to Moo (or Mouse or Moose), if you want to.
This is a difficult design goal, and might sometimes lose out to the other goals. However, this document will attempt to explain all the decisions.
This section will go into detail on all the current aspects of Mo, why decisions were made and any known concerns being thought about.
Mo uses extends to name its (single inheritance) parent.
extends
In the past, Mo supported multiple inheritance. This was consider suboptimal for a couple reasons. MI is generally frowned upon in Perl. It has problems that are better solved by roles. It also makes the BUILD call sequence much more difficult, which makes Moose compatibility hard. For this reason, we removee MI as a Mo feature. As a result, the code became much simpler.
It is highly doubtful that roles will be supported either. One should upgrade to Moo or higher when MI or roles become needed.
Mo uses a new method for construction.
new
It makes use of the BUILD method, for construction extension. Since it does this, it is only proper to call the SUPER::BUILD methods in the same order as the Moose family. Mo does this. This is not the minimal method of construction, but it is considered useful to have, so we do it. Hopefully this is not too big of a performance penalty. Speed optimations should be considered.
Mo uses has for generating accessors. Like Moose, it takes a name and a list of option/value pairs.
has
All options are silently ignored, except default and build. These were implemented because they are almost always needed, and the implementation is minimal. They are always lazy (like 'lazy => 1' in Moose). Since Mo will likely be rare in a precompile environment like in mod_perl, this is considered a speed gain. It also happens to be the more minimal way to code this.
default
build
If neither default nor build is requested, has will return a getter/setter that is optimized for speed.
All accessors are 'rw'. That means they are getter+setter methods. Since has ignores the is option, there is no special case for a read only accessor. The accessor (in 'get' mode) checks @_ for zero. This check could potentially be avoided if 'ro' were honored, but if one expects a 'ro' accessor, they expect it to fail on set. Given that, you would still need to check for zero args, so no speed gain is possible.
is
@_
Mo will not check or validate its usage. It is so minimal, that it will leave this up to the code author. Run time checks don't offer any gain when the usage is already correct. In a dynamic language like Perl, they only serve to make code slower. Plus, runtime checks would bloat the Mo code. Where would you draw the line? The best option is to leave them out, document things well, and let people write tests for their code, if they really need to. Upgrading from Mo is another alternative.
Mo.pm is currently golfed, compressed and unreadable by mere mortals. It has no comments or pod. The documentation is in Mo.pod and the comments are all in here. This makes Mo.pm a little black box of code that you can use anywhere.
When we hack on Mo.pm we run it through perltidy and it looks great. When we are done we run ./script/compress.pl on it and it turns into 2 lines.
The package declaration and $VERSION are on their own line. That way if someone inlines Mo, they can make their own package line more easily, and just grab line 2, the code.
This also helps because Module::Install barfs on parsing out the VERSION otherwise. We should fix Module::Install or coonsider stop using it for this.
We turn on strict and warnings for the user of Mo because it is really easy and offers great value. Also, all the other Moose family does it.
This is a list of eveything else.
The sad fact of Perl 5 is that OO isn't built in.
Moose not only added OO, it took OO to a new level. It is indeed a postmodern system. Unfortunately this comes at a (often hefty) performance price.
Attempts to make something similar but less hefty came in the forms of Mouse, Mousse and Moo. Mo is just the next attempt. It is a bare minimum OO framework, that still looks like Moose.
I've heard people argue that Mo doesn't belong in the Moose family, but those same people often feel the same way about Mouse and Moo. It won't stop me from trying to make something wonderful, that can be fairly easily upgraded to something possibly more wonderful.
With each of these attempts, less of the original Moose power is implemented. This annoys the hardcore Moose developers. But hopefully it pushes them towards making Moose better and better. I can imagine the day when Moose is a compiled in part of the perl interpreter and thus faster then Mo. At that point, all the others will become remnants of the past.
perl
In the meantime, I hope that Mo et al, helps people to get past their Moose inhibitions, and start using the Mo* that makes sense. I(ngy) have authored other OO base modules like Spiffy and Gloom. There are things about those that I sorely miss in the Moose family, but I have decided to stopping fighting the Moose. I for one, welcome our new giant antlered overlord.
To install Mo, copy and paste the appropriate command in to your terminal.
cpanm
cpanm Mo
CPAN shell
perl -MCPAN -e shell install Mo
For more information on module installation, please visit the detailed CPAN module installation guide.