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 |
# roughly the same as, with much lower memory usage: |
10 |
# |
11 |
# use strict qw(vars subs); |
12 |
# use feature qw(say state switch); |
13 |
# no warnings; |
14 |
|
15 |
=head1 DESCRIPTION |
16 |
|
17 |
This module implements some sane defaults for Perl programs, as defined by |
18 |
two typical (or not so typical - use your common sense) specimens of |
19 |
Perl coders. |
20 |
|
21 |
=over 4 |
22 |
|
23 |
=item no warnings |
24 |
|
25 |
Ah, the dreaded warnings. Even worse, the horribly dreaded C<-w> |
26 |
switch: Even though we don't care if other people use warnings (and |
27 |
certainly there are useful ones), a lot of warnings simply go against the |
28 |
spirit of Perl. |
29 |
|
30 |
Most prominently, the warnings related to C<undef>. There is nothing wrong |
31 |
with C<undef>: it has well-defined semantics, it is useful, and spitting |
32 |
out warnings you never asked for is just evil. |
33 |
|
34 |
So every module needs C<no warnings> to avoid somebody accidentally using |
35 |
C<-w> and forcing his bad standards on our code. No will do. Really, the |
36 |
C<-w> switch should only enable wanrings for the main program. |
37 |
|
38 |
Funnily enough, L<perllexwarn> explicitly mentions C<-w> (and not in a |
39 |
favourable way), but standard utilities, such as L<prove>, or MakeMaker |
40 |
when running C<make test> enable them blindly. |
41 |
|
42 |
=item use strict qw(subs vars) |
43 |
|
44 |
Using C<use strict> is definitely common sense, but C<use strict |
45 |
'refs'> definitely overshoots its usefulness. After almost two |
46 |
decades of Perl hacking, we decided that it does more harm than being |
47 |
useful. Specifically, constructs like these: |
48 |
|
49 |
@{ $var->[0] } |
50 |
|
51 |
Must be written like this (or similarly), when C<use strict 'refs'> is in |
52 |
scope, and C<$var> can legally be C<undef>: |
53 |
|
54 |
@{ $var->[0] || [] } |
55 |
|
56 |
This is annoying, and doesn't shield against obvious mistakes such as |
57 |
using C<"">, so one would even have to write (at least for the time |
58 |
being): |
59 |
|
60 |
@{ defined $var->[0] ? $var->[0] : [] } |
61 |
|
62 |
... which nobody with a bit of common sense would consider |
63 |
writing. |
64 |
|
65 |
Curiously enough, sometimes perl is not so strict, as this works even with |
66 |
C<use strict> in scope: |
67 |
|
68 |
for (@{ $var->[0] }) { ... |
69 |
|
70 |
If that isn't hipocrasy! And all that from a mere program! |
71 |
|
72 |
=item use feature qw(say state given) |
73 |
|
74 |
We found it annoying that we always have to enable extra features. If |
75 |
something breaks because it didn't anticipate future changes, so be |
76 |
it. 5.10 broke almost all our XS modules and nobody cared either (or at |
77 |
leats I know of nobody who really complained about gratitious changes - as |
78 |
opposed to bugs). |
79 |
|
80 |
Few modules that are not actively maintained work with newer versions of |
81 |
Perl, regardless of use feature or not, so a new major perl release means |
82 |
changes to many modules - new keywords are just the tip of the iceberg. |
83 |
|
84 |
If your code isn't alive, it's dead, jim - be an active maintainer. |
85 |
|
86 |
=item mucho reduced memory usage |
87 |
|
88 |
Just using all those pragmas mentioned in the SYNOPSIS together wastes |
89 |
<blink>I<< B<776> kilobytes >></blink> of precious memory in my perl, for |
90 |
I<every single perl process using our code>, which on our machines, is a |
91 |
lot. In comparison, this module only uses I<< B<four> >> kilobytes (I even |
92 |
had to write it out so it looks like more) of memory on the same platform. |
93 |
|
94 |
The money/time/effort/electricity invested in these gigabytes (probably |
95 |
petabytes globally!) of wasted memory could easily save 42 trees, and a |
96 |
kitten! |
97 |
|
98 |
Unfortunately, until everybods applies more common sense, there will still |
99 |
often be modules that pull in the monster pragmas. But one can hope... |
100 |
|
101 |
=cut |
102 |
|
103 |
package common::sense; |
104 |
|
105 |
our $VERSION = '1.0'; |
106 |
|
107 |
# no warnings; |
108 |
# use warnings qw(FATAL closed threads internal debugging pack substr malloc unopened portable prototype |
109 |
# inplace io pipe unpack regexp deprecated exiting redefine glob digit printf |
110 |
# utf8 layer reserved parenthesis taint closure); |
111 |
# BEGIN { warn join "", map "\\x$_", unpack "(H2)*", ${^WARNING_BITS} }; |
112 |
|
113 |
# overload should be included |
114 |
|
115 |
sub import { |
116 |
# verified with perl 5.8.0, 5.10.0 |
117 |
${^WARNING_BITS} = "\xfc\xff\xff\x00\xcf\xf3\xcf\xc0\xf3\xcc\x33\x03"; |
118 |
|
119 |
# use strict vars subs |
120 |
$^H |= 0x00000600; |
121 |
|
122 |
# use feature |
123 |
$^H{feature_switch} = |
124 |
$^H{feature_say} = |
125 |
$^H{feature_state} = 1; |
126 |
} |
127 |
|
128 |
1; |
129 |
|
130 |
=back |
131 |
|
132 |
=head1 THERE IS NO 'no common::sense'!!!! !!!! !! |
133 |
|
134 |
This module doesn't offer an unimport. First of all, it wastes even more |
135 |
memory, second, and more importantly, who with even a bit of common sense |
136 |
would want no common sense? |
137 |
|
138 |
=head1 STABILITY AND FUTURE VERSIONS |
139 |
|
140 |
Future versions might change just about everything in this module. We |
141 |
might test our modules and upload new ones working with newer versions of |
142 |
this module, and leave you standing in the rain because we didn't tell |
143 |
you. |
144 |
|
145 |
Most likely, we will pick a few useful warnings, instead of just disabling |
146 |
all of them. And maybe we will load some nifty modules that try to emulate |
147 |
C<say> or so with perls older than 5.10 (this module, of course, should |
148 |
work with older perl versions - supporting 5.8 for example is just common |
149 |
sense at this time. Maybe not in the future, but of course you can trust |
150 |
our common sense to be consistent with, uhm, our opinion). |
151 |
|
152 |
=head1 WHAT OTHER PEOPLE HAD TO SAY ABOUT THIS MODULE |
153 |
|
154 |
apeiron |
155 |
|
156 |
"... wow" |
157 |
"I hope common::sense is a joke." |
158 |
|
159 |
crab |
160 |
|
161 |
"i wonder how it would be if joerg schilling wrote perl modules." |
162 |
|
163 |
H.Merijn Brand |
164 |
|
165 |
"Just one more reason to drop JSON::XS from my distribution list" |
166 |
|
167 |
Pista Palo |
168 |
|
169 |
"Something in short supply these days..." |
170 |
|
171 |
Steffen Schwigon |
172 |
|
173 |
"This module is quite for sure *not* just a repetition of all the other |
174 |
'use strict, use warnings'-approaches, and it's also not the opposite. |
175 |
[...] And for its chosen middle-way it's also not the worst name ever. |
176 |
And everything is documented." |
177 |
|
178 |
BKB |
179 |
|
180 |
"[Deleted - thanks to Steffen Schwigon for pointing out this review was |
181 |
in error.]" |
182 |
|
183 |
Somni |
184 |
|
185 |
"the arrogance of the guy" |
186 |
"I swear he tacked somenoe else's name onto the module |
187 |
just so he could use the royal 'we' in the documentation" |
188 |
|
189 |
dngor |
190 |
|
191 |
"Heh. '"<elmex at ta-sa.org>"' The quotes are semantic |
192 |
distancing from that e-mail address." |
193 |
|
194 |
Jerad Pierce |
195 |
|
196 |
"Awful name (not a proper pragma), and the SYNOPSIS doesn't tell you |
197 |
anything either. Nor is it clear what features have to do with "common |
198 |
sense" or discipline." |
199 |
|
200 |
acme |
201 |
|
202 |
"THERE IS NO 'no common::sense'!!!! !!!! !!" |
203 |
|
204 |
apeiron (meta-comment) |
205 |
|
206 |
How about quoting this: get a clue, you fucktarded amoeba. |
207 |
|
208 |
=head1 AUTHOR |
209 |
|
210 |
Marc Lehmann <schmorp@schmorp.de> |
211 |
http://home.schmorp.de/ |
212 |
|
213 |
Robin Redeker, "<elmex at ta-sa.org>". |
214 |
|
215 |
=cut |
216 |
|