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