1Mo::Design(3)         User Contributed Perl Documentation        Mo::Design(3)
2
3
4

Overview

6       This is the design document for the Mo module.
7
8       It is intended to help people understand the thinking behind Mo.
9
10       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

Design Goals

15       Mo has the following design goals. These goals are all important and
16       have to be balanced against each other.
17
18       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
23           Single Inheritance
24               Mo should provide a mechanism for inheritance. At least single
25               inheritance.
26
27           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
32           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
36       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
41       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
47       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
53       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
58       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
63           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
68           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

Current Status

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
76       Inheritance
77           Mo uses "extends" to name its (single inheritance) parent.
78
79           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
86           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
89       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
93               use Mo 'build';
94
95       Accessors
96           Mo uses "has" for generating accessors. Like Moose, it takes a name
97           and a list of option/value pairs.
98
99           All options are silently ignored. Options like "default" and
100           "builder" are available as feature modules:
101
102               use Mo qw'default builder';
103
104           The default getter/setter is optimized for speed. It does no checks
105           and is always 'rw'.
106
107       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
117       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
123           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
126           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
130       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

Topics, Concerns and Issues

136       This is a list of everything else.
137
138   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
142           use Mo qw'foo bar';
143
144       This loads Mo::foo and Mo::bar. It calls the "e()" subroutine on each.
145
146   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
151   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
156       Golfing has now been automated using the power of PPI.
157
158   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
164       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
168   Why not Moose?
169       The sad fact of Perl 5 is that there's no object model built in.
170
171       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
175       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
179       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
184       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
191       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.
197
198
199
200perl v5.32.0                      2020-07-28                     Mo::Design(3)
Impressum