Profile of common/sense.pm

← Index
NYTProf Performance Profile «block view•line view•sub view»
For xt/tapper-mcp-scheduler-with-db-longrun.t
Run on Tue May 22 17:18:39 2012
Reported on Tue May 22 17:22:35 2012

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

Subroutines
Calls | P | F | Exclusive Time | Inclusive Time | Subroutine
--- | --- | --- | --- | --- | ---
2 | 2 | 2 | 32µs | 32µs | common::sense::::importcommon::sense::import

Call graph for these subroutines as a Graphviz dot language file.

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 sub import {
236 | 8 | 37µs |  |  | local $^W; # work around perl 5.16 spewing out warnings for next line
237 |  |  |  |  | # use warnings
238 |  |  |  |  | ${^WARNING_BITS} ^= ${^WARNING_BITS} ^ "\x3c\x3f\x33\x00\x0f\xf0\x0f\xc0\xf0\xfc\x33\x00";
239 |  |  |  |  | # use strict, use utf8;
240 |  |  |  |  | $^H |= 0x800600;
241 |  |  |  |  | # use feature
242 |  |  |  |  | $^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 |  |  |  |  |