1Mo::Design(3) User Contributed Perl Documentation Mo::Design(3)
2
6 This is the design document for the Mo module.
7 It is intended to help people understand the thinking behind Mo.
9 Like Mo, this document is a work in progress. Nothing here is in stone.
11 Everything is up for discussion. This document just explains the
12 current understanding, so you'll know where to start.
13
15 Mo has the following design goals. These goals are all important and
16 have to be balanced against each other.
17 Provide usable OO for Perl modules.
19 This includes at least the following. The current implementation
20 contains a bit more than this, but that is due to the other design
21 goals.
22 Single Inheritance
24 Mo should provide a mechanism for inheritance. At least single
25 inheritance.
26 Object Construction
28 Mo needs to provide a "new()" object constructor. It should
29 take a set of name/value pairs and return a new object
30 reference, blessed into the class' package name.
31 Attribute Declaration
33 Mo needs to provide a way to declare attribute accessing
34 methods. They need to be able to set and get values.
35 Be minimal
37 Mo only adds core features if they are considered very desirable
38 and can be implemented in a very small amount of code. Most
39 features are in external "feature" modules now.
40 Be useful
42 Mo wants to be the first module that Perl programmers reach for
43 when they need simple OO. To that end, it needs to be extremely
44 useful and support common idioms, even if they are not strictly
45 minimal.
46 Be fast
48 Mo should be about as fast as if you rolled your own OO. It should
49 be fast at both startup (compile) time and at run time. It should
50 especially strive to have fast accessors. Speed optimizations
51 should be simple and minimal.
52 Be embeddable
54 There may be situations where you want to inline Mo into your code.
55 For this reason, Mo will try to be in one minimal pure Perl file,
56 with no comments or documentation. See "Mo::Inline".
57 Easy upgrade/downgrade path with Moo
59 Moose has become the accepted style of OO in perl. Mo will attempt
60 to not do the things it does in an incompatible style to the
61 "Moose" family.
62 This is not to say that all Mo code can be switched to Moo, or vice
64 versa. This is to say that you should be able to find a style of
65 coding using the full capabilities of Mo, that you can switch to
66 Moo (or Mouse or Moose), if you want to.
67 This is a difficult design goal, and might sometimes lose out to
69 the other goals. However, this document will attempt to explain all
70 the decisions.
71
73 This section will go into detail on all the current aspects of Mo, why
74 decisions were made and any known concerns being thought about.
75 Inheritance
77 Mo uses "extends" to name its (single inheritance) parent.
78 In the past, Mo supported multiple inheritance. This was considered
80 suboptimal for a few reasons. MI is generally frowned upon in Perl.
81 It has problems that are better solved by roles. It also makes the
82 BUILD call sequence much more difficult, which makes Moose
83 compatibility hard. For these reasons, we removed MI as a Mo
84 feature. As a result, the code became much simpler.
85 It is highly doubtful that roles will be supported either. One
87 should upgrade to Moo or higher when MI or roles become needed.
88 Construction
90 Mo uses a "new" method for construction. It is super minimal and
91 fast. It does no calling of the BUILD sequence. To get that, use:
92 use Mo 'build';
94 Accessors
96 Mo uses "has" for generating accessors. Like Moose, it takes a name
97 and a list of option/value pairs.
98 All options are silently ignored. Options like "default" and
100 "builder" are available as feature modules:
101 use Mo qw'default builder';
103 The default getter/setter is optimized for speed. It does no checks
105 and is always 'rw'.
106 No runtime checks
108 Mo will not check or validate its usage. It is so minimal, that it
109 will leave this up to the code author. Run time checks don't offer
110 any gain when the usage is already correct. In a dynamic language
111 like Perl, they only serve to make code slower. Plus, runtime
112 checks would bloat the Mo code. Where would you draw the line? The
113 best option is to leave them out, document things well, and let
114 people write tests for their code, if they really need to.
115 Upgrading from Mo is another alternative.
116 Size matters
118 Mo.pm and its feature modules are golfed, compressed and unreadable
119 by mere mortals. It has no comments or pod. The documentation is in
120 Mo.pod and the comments are all in here. This makes Mo.pm a little
121 black box of code that you can use anywhere.
122 When we hack on Mo.pm we do it on src/. When we are done we run
124 "make -C src/" and it compresses stuff into "lib/".
125 The package declaration and $VERSION are on their own lines. That
127 way if someone inlines Mo, they can make their own package line
128 more easily, and just grab line 3, the code.
129 strict and warnings
131 We turn on strict and warnings for the user of Mo because it is
132 really easy and offers great value. Also, all the other Moose
133 family does it.
134
136 This is a list of everything else.
137 The feature system
139 Mo now has a decent feature system so that almost anything can be added
140 piecemeal. To use features you say:
141 use Mo qw'foo bar';
143 This loads Mo::foo and Mo::bar. It calls the "e()" subroutine on each.
145 1024 Size Limit
147 Mo.pm has a goal to never be larger than 1024 bytes. It has almost
148 never been larger than 500 bytes so far. It is currently under 450 and
149 should only go down (assuming we have the core features nailed down).
150 Automated Golfing
152 I want to start a policy that all of the golfing efforts will be made
153 via a script to sane code. We should automate testing both the ungolfed
154 and golfed code.
155 Golfing has now been automated using the power of PPI.
157 Moose and Moo creators like Mo
159 I can't (and am certain that I don't) speak for all the Moose
160 community, But I(ngy) personally know that stevan (creator of Moose)
161 and mst (creator of Moo) approve of Mo. They hang out on the #mo irc
162 channel, and mst has made a large portion of the code commits.
163 This is a sign of a healthy project, because hopefully we can all forge
165 a clear idea of how all these modules relate to each other and support
166 each other.
167 Why not Moose?
169 The sad fact of Perl 5 is that there's no object model built in.
170 Moose not only added an elegant, usable object model, it took OO to a
172 new level. It is indeed a postmodern system. Unfortunately this comes
173 at a (often hefty) performance price.
174 Attempts to make something similar but less hefty came in the forms of
176 Mouse, Mousse and Moo. Mo is just the next attempt. It is a bare
177 minimum OO framework, that still looks like Moose.
178 I've heard people argue that Mo doesn't belong in the Moose family, but
180 those same people often feel the same way about Mouse and Moo. It won't
181 stop me from trying to make something wonderful, that can be fairly
182 easily upgraded to something possibly more wonderful.
183 With each of these attempts, less of the original Moose power is
185 implemented. This annoys the hardcore Moose developers. But hopefully
186 it pushes them towards making Moose better and better. I can imagine
187 the day when Moose is a compiled in part of the "perl" interpreter and
188 thus faster then Mo. At that point, all the others will become remnants
189 of the past.
190 In the meantime, I hope that Mo et al, helps people to get past their
192 Moose inhibitions, and start using the Mo* that makes sense. I(ngy)
193 have authored other OO base modules like Spiffy and Gloom. There are
194 things about those that I sorely miss in the Moose family, but I have
195 decided to stopping fighting the Moose. I for one, welcome our new
196 giant antlered overlord.
197perl v5.32.0 2020-07-28 Mo::Design(3)