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