1 |
root |
1.1 |
=head1 NAME |
2 |
|
|
|
3 |
|
|
common::sense - save a tree AND a kitten, use common::sense! |
4 |
|
|
|
5 |
|
|
=head1 SYNOPSIS |
6 |
|
|
|
7 |
|
|
use common::sense; |
8 |
|
|
|
9 |
root |
1.19 |
# supposed to be the same, with much lower memory usage, as: |
10 |
root |
1.1 |
# |
11 |
|
|
# use strict qw(vars subs); |
12 |
|
|
# use feature qw(say state switch); |
13 |
|
|
# no warnings; |
14 |
root |
1.15 |
# use warnings qw(FATAL closed threads internal debugging pack substr malloc |
15 |
|
|
# unopened portable prototype inplace io pipe unpack regexp |
16 |
root |
1.16 |
# deprecated exiting glob digit printf utf8 layer |
17 |
root |
1.15 |
# reserved parenthesis taint closure semicolon); |
18 |
|
|
# no warnings qw(exec newline); |
19 |
root |
1.1 |
|
20 |
|
|
=head1 DESCRIPTION |
21 |
|
|
|
22 |
|
|
This module implements some sane defaults for Perl programs, as defined by |
23 |
root |
1.16 |
two typical (or not so typical - use your common sense) specimens of Perl |
24 |
root |
1.21 |
coders. In fact, after working out details on which warnings and strict |
25 |
|
|
modes to enable and make fatal, we found that we (and our code written so |
26 |
|
|
far, and others) fully agree on every option, even though we never used |
27 |
|
|
warnings before, so it seems this module indeed reflects a "common" sense |
28 |
|
|
among some long-time Perl coders. |
29 |
root |
1.1 |
|
30 |
|
|
=over 4 |
31 |
|
|
|
32 |
|
|
=item use strict qw(subs vars) |
33 |
|
|
|
34 |
|
|
Using C<use strict> is definitely common sense, but C<use strict |
35 |
root |
1.11 |
'refs'> definitely overshoots its usefulness. After almost two |
36 |
root |
1.1 |
decades of Perl hacking, we decided that it does more harm than being |
37 |
|
|
useful. Specifically, constructs like these: |
38 |
|
|
|
39 |
|
|
@{ $var->[0] } |
40 |
|
|
|
41 |
root |
1.4 |
Must be written like this (or similarly), when C<use strict 'refs'> is in |
42 |
|
|
scope, and C<$var> can legally be C<undef>: |
43 |
root |
1.1 |
|
44 |
|
|
@{ $var->[0] || [] } |
45 |
|
|
|
46 |
|
|
This is annoying, and doesn't shield against obvious mistakes such as |
47 |
root |
1.11 |
using C<"">, so one would even have to write (at least for the time |
48 |
|
|
being): |
49 |
root |
1.1 |
|
50 |
root |
1.18 |
@{ defined $var->[0] ? $var->[0] : [] } |
51 |
root |
1.1 |
|
52 |
|
|
... which nobody with a bit of common sense would consider |
53 |
root |
1.18 |
writing: clear code is clearly something else. |
54 |
root |
1.11 |
|
55 |
|
|
Curiously enough, sometimes perl is not so strict, as this works even with |
56 |
|
|
C<use strict> in scope: |
57 |
root |
1.1 |
|
58 |
|
|
for (@{ $var->[0] }) { ... |
59 |
|
|
|
60 |
root |
1.15 |
If that isn't hypocrisy! And all that from a mere program! |
61 |
|
|
|
62 |
root |
1.1 |
|
63 |
|
|
=item use feature qw(say state given) |
64 |
|
|
|
65 |
|
|
We found it annoying that we always have to enable extra features. If |
66 |
|
|
something breaks because it didn't anticipate future changes, so be |
67 |
root |
1.11 |
it. 5.10 broke almost all our XS modules and nobody cared either (or at |
68 |
root |
1.15 |
least I know of nobody who really complained about gratuitous changes - |
69 |
|
|
as opposed to bugs). |
70 |
root |
1.11 |
|
71 |
|
|
Few modules that are not actively maintained work with newer versions of |
72 |
|
|
Perl, regardless of use feature or not, so a new major perl release means |
73 |
|
|
changes to many modules - new keywords are just the tip of the iceberg. |
74 |
|
|
|
75 |
root |
1.15 |
If your code isn't alive, it's dead, Jim - be an active maintainer. |
76 |
|
|
|
77 |
|
|
|
78 |
root |
1.16 |
=item no warnings, but a lot of new errors |
79 |
root |
1.15 |
|
80 |
|
|
Ah, the dreaded warnings. Even worse, the horribly dreaded C<-w> |
81 |
|
|
switch: Even though we don't care if other people use warnings (and |
82 |
|
|
certainly there are useful ones), a lot of warnings simply go against the |
83 |
|
|
spirit of Perl. |
84 |
|
|
|
85 |
|
|
Most prominently, the warnings related to C<undef>. There is nothing wrong |
86 |
|
|
with C<undef>: it has well-defined semantics, it is useful, and spitting |
87 |
|
|
out warnings you never asked for is just evil. |
88 |
|
|
|
89 |
root |
1.16 |
The result was that every one of our modules did C<no warnings> in the |
90 |
|
|
past, to avoid somebody accidentally using and forcing his bad standards |
91 |
|
|
on our code. Of course, this switched off all warnings, even the useful |
92 |
|
|
ones. Not a good situation. Really, the C<-w> switch should only enable |
93 |
|
|
warnings for the main program only. |
94 |
root |
1.15 |
|
95 |
|
|
Funnily enough, L<perllexwarn> explicitly mentions C<-w> (and not in a |
96 |
|
|
favourable way, calling it outright "wrong"), but standard utilities, such |
97 |
|
|
as L<prove>, or MakeMaker when running C<make test>, still enable them |
98 |
|
|
blindly. |
99 |
|
|
|
100 |
root |
1.16 |
For version 2 of common::sense, we finally sat down a few hours and went |
101 |
|
|
through I<every single warning message>, identifiying - according to |
102 |
|
|
common sense - all the useful ones. |
103 |
root |
1.15 |
|
104 |
|
|
This resulted in the rather impressive list in the SYNOPSIS. When we |
105 |
|
|
weren't sure, we didn't include the warning, so the list might grow in |
106 |
|
|
the future (we might have made a mistake, too, so the list might shrink |
107 |
root |
1.16 |
as well). |
108 |
root |
1.15 |
|
109 |
|
|
Note the presence of C<FATAL> in the list: we do not think that the |
110 |
|
|
conditions caught by these warnings are worthy of a warning, we I<insist> |
111 |
root |
1.16 |
that they are worthy of I<stopping> your program, I<instantly>. They are |
112 |
|
|
I<bugs>! |
113 |
root |
1.15 |
|
114 |
|
|
Therefore we consider C<common::sense> to be much stricter than C<use |
115 |
|
|
warnings>, which is good if you are into strict things (we are not, |
116 |
|
|
actually, but these things tend to be subjective). |
117 |
|
|
|
118 |
|
|
After deciding on the list, we ran the module against all of our code that |
119 |
|
|
uses C<common::sense> (that is almost all of our code), and found only one |
120 |
|
|
occurence where one of them caused a problem: one of elmex's (unreleased) |
121 |
|
|
modules contained: |
122 |
|
|
|
123 |
|
|
$fmt =~ s/([^\s\[]*)\[( [^\]]* )\]/\x0$1\x1$2\x0/xgo; |
124 |
|
|
|
125 |
|
|
We quickly agreed that indeed the code should be changed, even though it |
126 |
|
|
happened to do the right thing when the warning was switched off. |
127 |
|
|
|
128 |
root |
1.11 |
|
129 |
|
|
=item mucho reduced memory usage |
130 |
|
|
|
131 |
|
|
Just using all those pragmas mentioned in the SYNOPSIS together wastes |
132 |
|
|
<blink>I<< B<776> kilobytes >></blink> of precious memory in my perl, for |
133 |
|
|
I<every single perl process using our code>, which on our machines, is a |
134 |
|
|
lot. In comparison, this module only uses I<< B<four> >> kilobytes (I even |
135 |
|
|
had to write it out so it looks like more) of memory on the same platform. |
136 |
root |
1.1 |
|
137 |
|
|
The money/time/effort/electricity invested in these gigabytes (probably |
138 |
|
|
petabytes globally!) of wasted memory could easily save 42 trees, and a |
139 |
|
|
kitten! |
140 |
|
|
|
141 |
root |
1.11 |
Unfortunately, until everybods applies more common sense, there will still |
142 |
|
|
often be modules that pull in the monster pragmas. But one can hope... |
143 |
|
|
|
144 |
root |
1.1 |
=cut |
145 |
|
|
|
146 |
root |
1.2 |
package common::sense; |
147 |
root |
1.1 |
|
148 |
root |
1.19 |
our $VERSION = '2.01'; |
149 |
root |
1.15 |
|
150 |
root |
1.19 |
# paste this into perl to find bitmask |
151 |
root |
1.1 |
|
152 |
root |
1.13 |
# no warnings; |
153 |
|
|
# use warnings qw(FATAL closed threads internal debugging pack substr malloc unopened portable prototype |
154 |
root |
1.16 |
# inplace io pipe unpack regexp deprecated exiting glob digit printf |
155 |
root |
1.14 |
# utf8 layer reserved parenthesis taint closure semicolon); |
156 |
|
|
# no warnings qw(exec newline); |
157 |
|
|
# BEGIN { warn join "", map "\\x$_", unpack "(H2)*", ${^WARNING_BITS}; exit 0 }; |
158 |
root |
1.13 |
|
159 |
|
|
# overload should be included |
160 |
|
|
|
161 |
root |
1.2 |
sub import { |
162 |
root |
1.13 |
# verified with perl 5.8.0, 5.10.0 |
163 |
root |
1.19 |
${^WARNING_BITS} ^= ${^WARNING_BITS} ^ "\xfc\x3f\xf3\x00\x0f\xf3\xcf\xc0\xf3\xfc\x33\x03"; |
164 |
root |
1.3 |
|
165 |
|
|
# use strict vars subs |
166 |
|
|
$^H |= 0x00000600; |
167 |
|
|
|
168 |
|
|
# use feature |
169 |
|
|
$^H{feature_switch} = |
170 |
|
|
$^H{feature_say} = |
171 |
|
|
$^H{feature_state} = 1; |
172 |
root |
1.1 |
} |
173 |
|
|
|
174 |
|
|
1; |
175 |
|
|
|
176 |
|
|
=back |
177 |
|
|
|
178 |
root |
1.5 |
=head1 THERE IS NO 'no common::sense'!!!! !!!! !! |
179 |
root |
1.4 |
|
180 |
|
|
This module doesn't offer an unimport. First of all, it wastes even more |
181 |
|
|
memory, second, and more importantly, who with even a bit of common sense |
182 |
|
|
would want no common sense? |
183 |
|
|
|
184 |
root |
1.5 |
=head1 STABILITY AND FUTURE VERSIONS |
185 |
|
|
|
186 |
|
|
Future versions might change just about everything in this module. We |
187 |
|
|
might test our modules and upload new ones working with newer versions of |
188 |
|
|
this module, and leave you standing in the rain because we didn't tell |
189 |
root |
1.15 |
you. In fact, we did so when switching from 1.0 to 2.0, which enabled gobs |
190 |
|
|
of warnings, and made them FATAL on top. |
191 |
root |
1.5 |
|
192 |
root |
1.15 |
Maybe we will load some nifty modules that try to emulate C<say> or so |
193 |
|
|
with perls older than 5.10 (this module, of course, should work with older |
194 |
|
|
perl versions - supporting 5.8 for example is just common sense at this |
195 |
|
|
time. Maybe not in the future, but of course you can trust our common |
196 |
|
|
sense to be consistent with, uhm, our opinion). |
197 |
root |
1.11 |
|
198 |
|
|
=head1 WHAT OTHER PEOPLE HAD TO SAY ABOUT THIS MODULE |
199 |
|
|
|
200 |
|
|
apeiron |
201 |
|
|
|
202 |
|
|
"... wow" |
203 |
|
|
"I hope common::sense is a joke." |
204 |
|
|
|
205 |
|
|
crab |
206 |
root |
1.5 |
|
207 |
root |
1.11 |
"i wonder how it would be if joerg schilling wrote perl modules." |
208 |
root |
1.7 |
|
209 |
root |
1.17 |
Adam Kennedy |
210 |
|
|
|
211 |
|
|
"Very interesting, efficient, and potentially something I'd use all the time." |
212 |
|
|
[...] |
213 |
|
|
"So no common::sense for me, alas." |
214 |
|
|
|
215 |
root |
1.11 |
H.Merijn Brand |
216 |
|
|
|
217 |
|
|
"Just one more reason to drop JSON::XS from my distribution list" |
218 |
root |
1.7 |
|
219 |
|
|
Pista Palo |
220 |
|
|
|
221 |
|
|
"Something in short supply these days..." |
222 |
|
|
|
223 |
|
|
Steffen Schwigon |
224 |
|
|
|
225 |
|
|
"This module is quite for sure *not* just a repetition of all the other |
226 |
|
|
'use strict, use warnings'-approaches, and it's also not the opposite. |
227 |
|
|
[...] And for its chosen middle-way it's also not the worst name ever. |
228 |
|
|
And everything is documented." |
229 |
|
|
|
230 |
|
|
BKB |
231 |
|
|
|
232 |
|
|
"[Deleted - thanks to Steffen Schwigon for pointing out this review was |
233 |
|
|
in error.]" |
234 |
|
|
|
235 |
|
|
Somni |
236 |
|
|
|
237 |
|
|
"the arrogance of the guy" |
238 |
|
|
"I swear he tacked somenoe else's name onto the module |
239 |
|
|
just so he could use the royal 'we' in the documentation" |
240 |
|
|
|
241 |
|
|
dngor |
242 |
|
|
|
243 |
|
|
"Heh. '"<elmex at ta-sa.org>"' The quotes are semantic |
244 |
|
|
distancing from that e-mail address." |
245 |
|
|
|
246 |
|
|
Jerad Pierce |
247 |
|
|
|
248 |
|
|
"Awful name (not a proper pragma), and the SYNOPSIS doesn't tell you |
249 |
|
|
anything either. Nor is it clear what features have to do with "common |
250 |
|
|
sense" or discipline." |
251 |
|
|
|
252 |
|
|
acme |
253 |
|
|
|
254 |
|
|
"THERE IS NO 'no common::sense'!!!! !!!! !!" |
255 |
|
|
|
256 |
root |
1.15 |
apeiron (meta-comment about us commenting^Wquoting his comment) |
257 |
root |
1.12 |
|
258 |
|
|
How about quoting this: get a clue, you fucktarded amoeba. |
259 |
|
|
|
260 |
root |
1.20 |
quanth |
261 |
|
|
|
262 |
|
|
common sense is beautiful, json::xs is fast, Anyevent, EV are fast and |
263 |
|
|
furious. I love mlehmannware ;) |
264 |
|
|
|
265 |
root |
1.19 |
=head1 FREQUQNTLY ASKED QUESTIONS |
266 |
|
|
|
267 |
|
|
Or frequently-come-up confusions. |
268 |
|
|
|
269 |
|
|
=over 4 |
270 |
|
|
|
271 |
|
|
=item Is this module meant to be serious? |
272 |
|
|
|
273 |
|
|
Yes, we would have put it under the C<Acme::> namespace otherwise. |
274 |
|
|
|
275 |
|
|
=item But the manpage is written in a funny/stupid/... way? |
276 |
|
|
|
277 |
|
|
This was meant to make it clear that our common sense is a subjective |
278 |
|
|
thing and other people can use their own notions, taking the steam out |
279 |
|
|
of anybody who might be offended (as some people are always offended no |
280 |
|
|
matter what you do). |
281 |
|
|
|
282 |
|
|
This was a failure. |
283 |
|
|
|
284 |
|
|
But we hope the manpage still is somewhat entertaining even though it |
285 |
|
|
explains boring rationale. |
286 |
|
|
|
287 |
|
|
=item Why do you impose your conventions on my code? |
288 |
|
|
|
289 |
|
|
For some reason people keep thinking that C<common::sense> imposes |
290 |
|
|
process-wide limits, even though the SYNOPSIS makes it clear that it works |
291 |
|
|
like other similar modules - only on the scope that uses them. |
292 |
|
|
|
293 |
|
|
So, no, we don't - nobody is forced to use this module, and using a module |
294 |
|
|
that relies on common::sense does not impose anything on you. |
295 |
|
|
|
296 |
|
|
=item Why do you think only your notion of common::sense is valid? |
297 |
|
|
|
298 |
|
|
Well, we don't, and have clearly written this in the documentation to |
299 |
|
|
every single release. We were just faster than anybody else w.r.t. to |
300 |
|
|
grabbing the namespace. |
301 |
|
|
|
302 |
|
|
=item But everybody knows that you have to use strict and use warnings, |
303 |
|
|
why do you disable them? |
304 |
|
|
|
305 |
|
|
Well, we don't do this either - we selectively disagree with the |
306 |
|
|
usefulness of some warnings over others. This module is aimed at |
307 |
|
|
experienced Perl programmers, not people migrating from other languages |
308 |
|
|
who might be surprised about stuff such as C<undef>. |
309 |
|
|
|
310 |
|
|
In fact, this module is considerably I<more> strict than the canonical |
311 |
|
|
C<use strict; use warnings>, as it makes all warnings fatal in nature, so |
312 |
|
|
you can get away with as many things as with the canonical approach. |
313 |
|
|
|
314 |
|
|
This was not implemented in version 1.0 because of the daunting number |
315 |
|
|
of warning categories and the difficulty in getting exactly the set of |
316 |
|
|
warnings you wish (i.e. look at the SYNOPSIS in how complicated it is to |
317 |
|
|
get a specific set of warnings - it is not reasonable to put this into |
318 |
|
|
every module, the maintainance effort would be enourmous). |
319 |
|
|
|
320 |
|
|
=item But many modules C<use strict> or C<use warnings>, so the memory |
321 |
|
|
savings do not apply? |
322 |
|
|
|
323 |
|
|
I am suddenly so sad. |
324 |
|
|
|
325 |
|
|
But yes, that's true. Fortunately C<common::sense> still uses only a |
326 |
|
|
miniscule amount of RAM. |
327 |
|
|
|
328 |
|
|
=item But it adds another dependency to your modules! |
329 |
|
|
|
330 |
|
|
It's a fact, yeah. But it's trivial to install, most popular modules have |
331 |
|
|
many more dependencies and we consider dependencies a good thing - it |
332 |
|
|
leads to better APIs, more thought about interworking of modules and so |
333 |
|
|
on. |
334 |
|
|
|
335 |
|
|
=item But! But! |
336 |
|
|
|
337 |
|
|
Yeah, we know. |
338 |
|
|
|
339 |
|
|
=back |
340 |
|
|
|
341 |
root |
1.1 |
=head1 AUTHOR |
342 |
|
|
|
343 |
|
|
Marc Lehmann <schmorp@schmorp.de> |
344 |
|
|
http://home.schmorp.de/ |
345 |
|
|
|
346 |
root |
1.4 |
Robin Redeker, "<elmex at ta-sa.org>". |
347 |
|
|
|
348 |
root |
1.1 |
=cut |
349 |
|
|
|