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