1 |
#! perl-000 |
2 |
|
3 |
open STDOUT, ">$ARGV[0]~" |
4 |
or die "$ARGV[0]~: $!"; |
5 |
|
6 |
our $WARN; |
7 |
our $H; |
8 |
our %H; |
9 |
|
10 |
BEGIN { |
11 |
$H = $^H; |
12 |
$WARN = ${^WARNING_BITS}; |
13 |
} |
14 |
|
15 |
use utf8; |
16 |
use strict qw(subs vars); |
17 |
|
18 |
BEGIN { |
19 |
if ($] >= 5.010) { |
20 |
require feature; |
21 |
feature->import (qw(say state switch)); |
22 |
} |
23 |
if ($] >= 5.012) { |
24 |
feature->import (qw(unicode_strings)); |
25 |
} |
26 |
if ($] >= 5.016) { |
27 |
feature->import (qw(current_sub fc evalbytes)); |
28 |
feature->unimport (qw(array_base)); |
29 |
} |
30 |
} |
31 |
|
32 |
no warnings; |
33 |
use warnings qw(FATAL closed threads internal debugging pack malloc portable prototype |
34 |
inplace io pipe unpack deprecated glob digit printf |
35 |
layer reserved taint closure semicolon); |
36 |
no warnings qw(exec newline unopened); |
37 |
|
38 |
BEGIN { |
39 |
$H = $^H & ~$H; |
40 |
$WARN = ${^WARNING_BITS} & ~$WARN; |
41 |
%H = %^H; |
42 |
} |
43 |
|
44 |
while (<DATA>) { |
45 |
if (/^IMPORT/) { |
46 |
print " # use warnings\n"; |
47 |
printf " \${^WARNING_BITS} ^= \${^WARNING_BITS} ^ \"%s\";\n", |
48 |
join "", map "\\x$_", unpack "(H2)*", $WARN; |
49 |
print " # use strict, use utf8; use feature;\n"; |
50 |
printf " \$^H |= 0x%x;\n", $H; |
51 |
|
52 |
if (my @features = grep /^feature_/, keys %H) { |
53 |
print " \@^H{qw(@features)} = (1) x ", (scalar @features), ";\n"; |
54 |
} |
55 |
} else { |
56 |
print; |
57 |
} |
58 |
} |
59 |
|
60 |
close STDOUT; |
61 |
rename "$ARGV[0]~", $ARGV[0]; |
62 |
|
63 |
__DATA__ |
64 |
|
65 |
=head1 NAME |
66 |
|
67 |
common::sense - save a tree AND a kitten, use common::sense! |
68 |
|
69 |
=head1 SYNOPSIS |
70 |
|
71 |
use common::sense; |
72 |
|
73 |
# Supposed to be mostly the same, with much lower memory usage, as: |
74 |
|
75 |
# use utf8; |
76 |
# use strict qw(vars subs); |
77 |
# use feature qw(say state switch); |
78 |
# use feature qw(unicode_strings unicode_eval current_sub fc evalbytes); |
79 |
# no feature qw(array_base); |
80 |
# no warnings; |
81 |
# use warnings qw(FATAL closed threads internal debugging pack |
82 |
# portable prototype inplace io pipe unpack malloc |
83 |
# deprecated glob digit printf layer |
84 |
# reserved taint closure semicolon); |
85 |
# no warnings qw(exec newline unopened); |
86 |
|
87 |
=head1 DESCRIPTION |
88 |
|
89 |
“Nothing is more fairly distributed than common sense: no one thinks |
90 |
he needs more of it than he already has.” |
91 |
|
92 |
– René Descartes |
93 |
|
94 |
This module implements some sane defaults for Perl programs, as defined by |
95 |
two typical (or not so typical - use your common sense) specimens of Perl |
96 |
coders. In fact, after working out details on which warnings and strict |
97 |
modes to enable and make fatal, we found that we (and our code written so |
98 |
far, and others) fully agree on every option, even though we never used |
99 |
warnings before, so it seems this module indeed reflects a "common" sense |
100 |
among some long-time Perl coders. |
101 |
|
102 |
The basic philosophy behind the choices made in common::sense can be |
103 |
summarised as: "enforcing strict policies to catch as many bugs as |
104 |
possible, while at the same time, not limiting the expressive power |
105 |
available to the programmer". |
106 |
|
107 |
Two typical examples of how this philosophy is applied in practise is the |
108 |
handling of uninitialised and malloc warnings: |
109 |
|
110 |
=over 4 |
111 |
|
112 |
=item I<uninitialised> |
113 |
|
114 |
C<undef> is a well-defined feature of perl, and enabling warnings for |
115 |
using it rarely catches any bugs, but considerably limits you in what you |
116 |
can do, so uninitialised warnings are disabled. |
117 |
|
118 |
=item I<malloc> |
119 |
|
120 |
Freeing something twice on the C level is a serious bug, usually causing |
121 |
memory corruption. It often leads to side effects much later in the |
122 |
program and there are no advantages to not reporting this, so malloc |
123 |
warnings are fatal by default. |
124 |
|
125 |
=back |
126 |
|
127 |
Unfortunately, there is no fine-grained warning control in perl, so often |
128 |
whole groups of useful warnings had to be excluded because of a single |
129 |
useless warning (for example, perl puts an arbitrary limit on the length |
130 |
of text you can match with some regexes before emitting a warning, making |
131 |
the whole C<regexp> category useless). |
132 |
|
133 |
What follows is a more thorough discussion of what this module does, |
134 |
and why it does it, and what the advantages (and disadvantages) of this |
135 |
approach are. |
136 |
|
137 |
=head1 RATIONALE |
138 |
|
139 |
=over 4 |
140 |
|
141 |
=item use utf8 |
142 |
|
143 |
While it's not common sense to write your programs in UTF-8, it's quickly |
144 |
becoming the most common encoding, is the designated future default |
145 |
encoding for perl sources, and the most convenient encoding available |
146 |
(you can do really nice quoting tricks...). Experience has shown that our |
147 |
programs were either all pure ascii or utf-8, both of which will stay the |
148 |
same. |
149 |
|
150 |
There are few drawbacks to enabling UTF-8 source code by default (mainly |
151 |
some speed hits due to bugs in older versions of perl), so this module |
152 |
enables UTF-8 source code encoding by default. |
153 |
|
154 |
|
155 |
=item use strict qw(subs vars) |
156 |
|
157 |
Using C<use strict> is definitely common sense, but C<use strict |
158 |
'refs'> definitely overshoots its usefulness. After almost two |
159 |
decades of Perl hacking, we decided that it does more harm than being |
160 |
useful. Specifically, constructs like these: |
161 |
|
162 |
@{ $var->[0] } |
163 |
|
164 |
Must be written like this (or similarly), when C<use strict 'refs'> is in |
165 |
scope, and C<$var> can legally be C<undef>: |
166 |
|
167 |
@{ $var->[0] || [] } |
168 |
|
169 |
This is annoying, and doesn't shield against obvious mistakes such as |
170 |
using C<"">, so one would even have to write (at least for the time |
171 |
being): |
172 |
|
173 |
@{ defined $var->[0] ? $var->[0] : [] } |
174 |
|
175 |
... which nobody with a bit of common sense would consider |
176 |
writing: clear code is clearly something else. |
177 |
|
178 |
Curiously enough, sometimes perl is not so strict, as this works even with |
179 |
C<use strict> in scope: |
180 |
|
181 |
for (@{ $var->[0] }) { ... |
182 |
|
183 |
If that isn't hypocrisy! And all that from a mere program! |
184 |
|
185 |
|
186 |
=item use feature qw(say state given ...) |
187 |
|
188 |
We found it annoying that we always have to enable extra features. If |
189 |
something breaks because it didn't anticipate future changes, so be |
190 |
it. 5.10 broke almost all our XS modules and nobody cared either (or at |
191 |
least I know of nobody who really complained about gratuitous changes - |
192 |
as opposed to bugs). |
193 |
|
194 |
Few modules that are not actively maintained work with newer versions of |
195 |
Perl, regardless of use feature or not, so a new major perl release means |
196 |
changes to many modules - new keywords are just the tip of the iceberg. |
197 |
|
198 |
If your code isn't alive, it's dead, Jim - be an active maintainer. |
199 |
|
200 |
But nobody forces you to use those extra features in modules meant for |
201 |
older versions of perl - common::sense of course works there as well. |
202 |
There is also an important other mode where having additional features by |
203 |
default is useful: commandline hacks and internal use scripts: See "much |
204 |
reduced typing", below. |
205 |
|
206 |
There is one notable exception: C<unicode_eval> is not enabled by |
207 |
default. In our opinion, C<use feature> had one main effect - newer perl |
208 |
versions don't value backwards compatibility and the ability to write |
209 |
modules for multiple perl versions much, after all, you can use feature. |
210 |
|
211 |
C<unicode_eval> doesn't add a new feature, it breaks an existing function. |
212 |
|
213 |
=item no warnings, but a lot of new errors |
214 |
|
215 |
Ah, the dreaded warnings. Even worse, the horribly dreaded C<-w> |
216 |
switch: Even though we don't care if other people use warnings (and |
217 |
certainly there are useful ones), a lot of warnings simply go against the |
218 |
spirit of Perl. |
219 |
|
220 |
Most prominently, the warnings related to C<undef>. There is nothing wrong |
221 |
with C<undef>: it has well-defined semantics, it is useful, and spitting |
222 |
out warnings you never asked for is just evil. |
223 |
|
224 |
The result was that every one of our modules did C<no warnings> in the |
225 |
past, to avoid somebody accidentally using and forcing his bad standards |
226 |
on our code. Of course, this switched off all warnings, even the useful |
227 |
ones. Not a good situation. Really, the C<-w> switch should only enable |
228 |
warnings for the main program only. |
229 |
|
230 |
Funnily enough, L<perllexwarn> explicitly mentions C<-w> (and not in a |
231 |
favourable way, calling it outright "wrong"), but standard utilities, such |
232 |
as L<prove>, or MakeMaker when running C<make test>, still enable them |
233 |
blindly. |
234 |
|
235 |
For version 2 of common::sense, we finally sat down a few hours and went |
236 |
through I<every single warning message>, identifiying - according to |
237 |
common sense - all the useful ones. |
238 |
|
239 |
This resulted in the rather impressive list in the SYNOPSIS. When we |
240 |
weren't sure, we didn't include the warning, so the list might grow in |
241 |
the future (we might have made a mistake, too, so the list might shrink |
242 |
as well). |
243 |
|
244 |
Note the presence of C<FATAL> in the list: we do not think that the |
245 |
conditions caught by these warnings are worthy of a warning, we I<insist> |
246 |
that they are worthy of I<stopping> your program, I<instantly>. They are |
247 |
I<bugs>! |
248 |
|
249 |
Therefore we consider C<common::sense> to be much stricter than C<use |
250 |
warnings>, which is good if you are into strict things (we are not, |
251 |
actually, but these things tend to be subjective). |
252 |
|
253 |
After deciding on the list, we ran the module against all of our code that |
254 |
uses C<common::sense> (that is almost all of our code), and found only one |
255 |
occurence where one of them caused a problem: one of elmex's (unreleased) |
256 |
modules contained: |
257 |
|
258 |
$fmt =~ s/([^\s\[]*)\[( [^\]]* )\]/\x0$1\x1$2\x0/xgo; |
259 |
|
260 |
We quickly agreed that indeed the code should be changed, even though it |
261 |
happened to do the right thing when the warning was switched off. |
262 |
|
263 |
|
264 |
=item much reduced typing |
265 |
|
266 |
Especially with version 2.0 of common::sense, the amount of boilerplate |
267 |
code you need to add to gte I<this> policy is daunting. Nobody would write |
268 |
this out in throwaway scripts, commandline hacks or in quick internal-use |
269 |
scripts. |
270 |
|
271 |
By using common::sense you get a defined set of policies (ours, but maybe |
272 |
yours, too, if you accept them), and they are easy to apply to your |
273 |
scripts: typing C<use common::sense;> is even shorter than C<use warnings; |
274 |
use strict; use feature ...>. |
275 |
|
276 |
And you can immediately use the features of your installed perl, which |
277 |
is more difficult in code you release, but not usually an issue for |
278 |
internal-use code (downgrades of your production perl should be rare, |
279 |
right?). |
280 |
|
281 |
|
282 |
=item mucho reduced memory usage |
283 |
|
284 |
Just using all those pragmas mentioned in the SYNOPSIS together wastes |
285 |
<blink>I<< B<776> kilobytes >></blink> of precious memory in my perl, for |
286 |
I<every single perl process using our code>, which on our machines, is a |
287 |
lot. In comparison, this module only uses I<< B<four> >> kilobytes (I even |
288 |
had to write it out so it looks like more) of memory on the same platform. |
289 |
|
290 |
The money/time/effort/electricity invested in these gigabytes (probably |
291 |
petabytes globally!) of wasted memory could easily save 42 trees, and a |
292 |
kitten! |
293 |
|
294 |
Unfortunately, until everybods applies more common sense, there will still |
295 |
often be modules that pull in the monster pragmas. But one can hope... |
296 |
|
297 |
=cut |
298 |
|
299 |
package common::sense; |
300 |
|
301 |
our $VERSION = '3.6'; |
302 |
|
303 |
# overload should be included |
304 |
|
305 |
sub import { |
306 |
local $^W; # work around perl 5.16 spewing out warnings for next statement |
307 |
IMPORT |
308 |
} |
309 |
|
310 |
1; |
311 |
|
312 |
=back |
313 |
|
314 |
=head1 THERE IS NO 'no common::sense'!!!! !!!! !! |
315 |
|
316 |
This module doesn't offer an unimport. First of all, it wastes even more |
317 |
memory, second, and more importantly, who with even a bit of common sense |
318 |
would want no common sense? |
319 |
|
320 |
=head1 STABILITY AND FUTURE VERSIONS |
321 |
|
322 |
Future versions might change just about everything in this module. We |
323 |
might test our modules and upload new ones working with newer versions of |
324 |
this module, and leave you standing in the rain because we didn't tell |
325 |
you. In fact, we did so when switching from 1.0 to 2.0, which enabled gobs |
326 |
of warnings, and made them FATAL on top. |
327 |
|
328 |
Maybe we will load some nifty modules that try to emulate C<say> or so |
329 |
with perls older than 5.10 (this module, of course, should work with older |
330 |
perl versions - supporting 5.8 for example is just common sense at this |
331 |
time. Maybe not in the future, but of course you can trust our common |
332 |
sense to be consistent with, uhm, our opinion). |
333 |
|
334 |
=head1 WHAT OTHER PEOPLE HAD TO SAY ABOUT THIS MODULE |
335 |
|
336 |
apeiron |
337 |
|
338 |
"... wow" |
339 |
"I hope common::sense is a joke." |
340 |
|
341 |
crab |
342 |
|
343 |
"i wonder how it would be if joerg schilling wrote perl modules." |
344 |
|
345 |
Adam Kennedy |
346 |
|
347 |
"Very interesting, efficient, and potentially something I'd use all the time." |
348 |
[...] |
349 |
"So no common::sense for me, alas." |
350 |
|
351 |
H.Merijn Brand |
352 |
|
353 |
"Just one more reason to drop JSON::XS from my distribution list" |
354 |
|
355 |
Pista Palo |
356 |
|
357 |
"Something in short supply these days..." |
358 |
|
359 |
Steffen Schwigon |
360 |
|
361 |
"This module is quite for sure *not* just a repetition of all the other |
362 |
'use strict, use warnings'-approaches, and it's also not the opposite. |
363 |
[...] And for its chosen middle-way it's also not the worst name ever. |
364 |
And everything is documented." |
365 |
|
366 |
BKB |
367 |
|
368 |
"[Deleted - thanks to Steffen Schwigon for pointing out this review was |
369 |
in error.]" |
370 |
|
371 |
Somni |
372 |
|
373 |
"the arrogance of the guy" |
374 |
"I swear he tacked somenoe else's name onto the module |
375 |
just so he could use the royal 'we' in the documentation" |
376 |
|
377 |
Anonymous Monk |
378 |
|
379 |
"You just gotta love this thing, its got META.json!!!" |
380 |
|
381 |
dngor |
382 |
|
383 |
"Heh. '"<elmex at ta-sa.org>"' The quotes are semantic |
384 |
distancing from that e-mail address." |
385 |
|
386 |
Jerad Pierce |
387 |
|
388 |
"Awful name (not a proper pragma), and the SYNOPSIS doesn't tell you |
389 |
anything either. Nor is it clear what features have to do with "common |
390 |
sense" or discipline." |
391 |
|
392 |
acme |
393 |
|
394 |
"THERE IS NO 'no common::sense'!!!! !!!! !!" |
395 |
|
396 |
apeiron (meta-comment about us commenting^Wquoting his comment) |
397 |
|
398 |
"How about quoting this: get a clue, you fucktarded amoeba." |
399 |
|
400 |
quanth |
401 |
|
402 |
"common sense is beautiful, json::xs is fast, Anyevent, EV are fast and |
403 |
furious. I love mlehmannware ;)" |
404 |
|
405 |
apeiron |
406 |
|
407 |
"... it's mlehmann's view of what common sense is. His view of common |
408 |
sense is certainly uncommon, insofar as anyone with a clue disagrees |
409 |
with him." |
410 |
|
411 |
apeiron (another meta-comment) |
412 |
|
413 |
"apeiron wonders if his little informant is here to steal more quotes" |
414 |
|
415 |
ew73 |
416 |
|
417 |
"... I never got past the SYNOPSIS before calling it shit." |
418 |
[...] |
419 |
How come no one ever quotes me. :(" |
420 |
|
421 |
chip (not willing to explain his cryptic questions about links in Changes files) |
422 |
|
423 |
"I'm willing to ask the question I've asked. I'm not willing to go |
424 |
through the whole dance you apparently have choreographed. Either |
425 |
answer the completely obvious question, or tell me to fuck off again." |
426 |
|
427 |
=head1 FREQUENTLY ASKED QUESTIONS |
428 |
|
429 |
Or frequently-come-up confusions. |
430 |
|
431 |
=over 4 |
432 |
|
433 |
=item Is this module meant to be serious? |
434 |
|
435 |
Yes, we would have put it under the C<Acme::> namespace otherwise. |
436 |
|
437 |
=item But the manpage is written in a funny/stupid/... way? |
438 |
|
439 |
This was meant to make it clear that our common sense is a subjective |
440 |
thing and other people can use their own notions, taking the steam out |
441 |
of anybody who might be offended (as some people are always offended no |
442 |
matter what you do). |
443 |
|
444 |
This was a failure. |
445 |
|
446 |
But we hope the manpage still is somewhat entertaining even though it |
447 |
explains boring rationale. |
448 |
|
449 |
=item Why do you impose your conventions on my code? |
450 |
|
451 |
For some reason people keep thinking that C<common::sense> imposes |
452 |
process-wide limits, even though the SYNOPSIS makes it clear that it works |
453 |
like other similar modules - i.e. only within the scope that C<use>s them. |
454 |
|
455 |
So, no, we don't - nobody is forced to use this module, and using a module |
456 |
that relies on common::sense does not impose anything on you. |
457 |
|
458 |
=item Why do you think only your notion of common::sense is valid? |
459 |
|
460 |
Well, we don't, and have clearly written this in the documentation to |
461 |
every single release. We were just faster than anybody else w.r.t. to |
462 |
grabbing the namespace. |
463 |
|
464 |
=item But everybody knows that you have to use strict and use warnings, |
465 |
why do you disable them? |
466 |
|
467 |
Well, we don't do this either - we selectively disagree with the |
468 |
usefulness of some warnings over others. This module is aimed at |
469 |
experienced Perl programmers, not people migrating from other languages |
470 |
who might be surprised about stuff such as C<undef>. On the other hand, |
471 |
this does not exclude the usefulness of this module for total newbies, due |
472 |
to its strictness in enforcing policy, while at the same time not limiting |
473 |
the expressive power of perl. |
474 |
|
475 |
This module is considerably I<more> strict than the canonical C<use |
476 |
strict; use warnings>, as it makes all its warnings fatal in nature, so |
477 |
you can not get away with as many things as with the canonical approach. |
478 |
|
479 |
This was not implemented in version 1.0 because of the daunting number |
480 |
of warning categories and the difficulty in getting exactly the set of |
481 |
warnings you wish (i.e. look at the SYNOPSIS in how complicated it is to |
482 |
get a specific set of warnings - it is not reasonable to put this into |
483 |
every module, the maintenance effort would be enourmous). |
484 |
|
485 |
=item But many modules C<use strict> or C<use warnings>, so the memory |
486 |
savings do not apply? |
487 |
|
488 |
I suddenly feel sad... |
489 |
|
490 |
But yes, that's true. Fortunately C<common::sense> still uses only a |
491 |
miniscule amount of RAM. |
492 |
|
493 |
=item But it adds another dependency to your modules! |
494 |
|
495 |
It's a fact, yeah. But it's trivial to install, most popular modules have |
496 |
many more dependencies and we consider dependencies a good thing - it |
497 |
leads to better APIs, more thought about interworking of modules and so |
498 |
on. |
499 |
|
500 |
=item Why do you use JSON and not YAML for your META.yml? |
501 |
|
502 |
This is not true - YAML supports a large subset of JSON, and this subset |
503 |
is what META.yml is written in, so it would be correct to say "the |
504 |
META.yml is written in a common subset of YAML and JSON". |
505 |
|
506 |
The META.yml follows the YAML, JSON and META.yml specifications, and is |
507 |
correctly parsed by CPAN, so if you have trouble with it, the problem is |
508 |
likely on your side. |
509 |
|
510 |
=item But! But! |
511 |
|
512 |
Yeah, we know. |
513 |
|
514 |
=back |
515 |
|
516 |
=head1 AUTHOR |
517 |
|
518 |
Marc Lehmann <schmorp@schmorp.de> |
519 |
http://home.schmorp.de/ |
520 |
|
521 |
Robin Redeker, "<elmex at ta-sa.org>". |
522 |
|
523 |
=cut |
524 |
|