1 |
root |
1.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 |
root |
1.4 |
=item no warnings |
24 |
|
|
|
25 |
|
|
The dreaded warnings. Even worse, the horribly dreaded C<-w> switch. Even |
26 |
|
|
though we don't care if other people use warnings (and certainly there are |
27 |
|
|
useful ones), a lot of warnings simply go against the spirit of Perl, most |
28 |
|
|
prominently, the warnings related to C<undef>. There is nothing wrong with |
29 |
|
|
C<undef>: it has well-defined semantics, it is useful, and spitting out |
30 |
|
|
warnings you never asked for is just evil. |
31 |
|
|
|
32 |
|
|
So every module needs C<no warnings> to avoid somebody accidentally using |
33 |
|
|
C<-w> and forcing his bad standards on our code. No will do. |
34 |
|
|
|
35 |
|
|
Funnily enough, L<perllexwarn> explicitly mentions C<-w> (and not in a |
36 |
|
|
favourable way), but standard utilities, such as L<prove>, or MakeMaker |
37 |
|
|
when running C<make test> enable them blindly. |
38 |
|
|
|
39 |
root |
1.1 |
=item use strict qw(subs vars) |
40 |
|
|
|
41 |
|
|
Using C<use strict> is definitely common sense, but C<use strict |
42 |
|
|
'refs'> definitely overshoots it's usefulness. After almost two |
43 |
|
|
decades of Perl hacking, we decided that it does more harm than being |
44 |
|
|
useful. Specifically, constructs like these: |
45 |
|
|
|
46 |
|
|
@{ $var->[0] } |
47 |
|
|
|
48 |
root |
1.4 |
Must be written like this (or similarly), when C<use strict 'refs'> is in |
49 |
|
|
scope, and C<$var> can legally be C<undef>: |
50 |
root |
1.1 |
|
51 |
|
|
@{ $var->[0] || [] } |
52 |
|
|
|
53 |
|
|
This is annoying, and doesn't shield against obvious mistakes such as |
54 |
|
|
using C<"">, so one would even have to write: |
55 |
|
|
|
56 |
|
|
@{ defined $var->[0] ? $var->[0] : [] } |
57 |
|
|
|
58 |
|
|
... which nobody with a bit of common sense would consider |
59 |
|
|
writing. Curiously enough, sometimes, perl is not so strict, as this works |
60 |
|
|
even with C<use strict> in scope: |
61 |
|
|
|
62 |
|
|
for (@{ $var->[0] }) { ... |
63 |
|
|
|
64 |
|
|
If that isnt hipocrasy! And all that from a mere program! |
65 |
|
|
|
66 |
|
|
=item use feature qw(say state given) |
67 |
|
|
|
68 |
|
|
We found it annoying that we always have to enable extra features. If |
69 |
|
|
something breaks because it didn't anticipate future changes, so be |
70 |
|
|
it. 5.10 broke almost all our XS modules and nobody cared either - and few |
71 |
|
|
modules that are no longer maintained work with newer versions of Perl, |
72 |
|
|
regardless of use feature. |
73 |
|
|
|
74 |
root |
1.4 |
If your code isn't alive, it's dead, jim. |
75 |
root |
1.1 |
|
76 |
|
|
=item much less memory |
77 |
|
|
|
78 |
root |
1.9 |
Just using all those pragmas together wastes <blink>I<< B<776> kilobytes |
79 |
root |
1.1 |
>></blink> of precious memory in my perl, for I<every single perl process |
80 |
root |
1.3 |
using our code>, which on our machines, is a lot. In comparison, this |
81 |
|
|
module only uses I<< B<four> >> kilobytes (I even had to write it out so |
82 |
|
|
it looks like more) of memory on the same platform. |
83 |
root |
1.1 |
|
84 |
|
|
The money/time/effort/electricity invested in these gigabytes (probably |
85 |
|
|
petabytes globally!) of wasted memory could easily save 42 trees, and a |
86 |
|
|
kitten! |
87 |
|
|
|
88 |
|
|
=cut |
89 |
|
|
|
90 |
root |
1.2 |
package common::sense; |
91 |
root |
1.1 |
|
92 |
root |
1.7 |
our $VERSION = '0.04'; |
93 |
root |
1.1 |
|
94 |
root |
1.2 |
sub import { |
95 |
root |
1.3 |
# no warnings |
96 |
root |
1.2 |
${^WARNING_BITS} ^= ${^WARNING_BITS}; |
97 |
root |
1.3 |
|
98 |
|
|
# use strict vars subs |
99 |
|
|
$^H |= 0x00000600; |
100 |
|
|
|
101 |
|
|
# use feature |
102 |
|
|
$^H{feature_switch} = |
103 |
|
|
$^H{feature_say} = |
104 |
|
|
$^H{feature_state} = 1; |
105 |
root |
1.1 |
} |
106 |
|
|
|
107 |
|
|
1; |
108 |
|
|
|
109 |
|
|
=back |
110 |
|
|
|
111 |
root |
1.5 |
=head1 THERE IS NO 'no common::sense'!!!! !!!! !! |
112 |
root |
1.4 |
|
113 |
|
|
This module doesn't offer an unimport. First of all, it wastes even more |
114 |
|
|
memory, second, and more importantly, who with even a bit of common sense |
115 |
|
|
would want no common sense? |
116 |
|
|
|
117 |
root |
1.5 |
=head1 STABILITY AND FUTURE VERSIONS |
118 |
|
|
|
119 |
|
|
Future versions might change just about everything in this module. We |
120 |
|
|
might test our modules and upload new ones working with newer versions of |
121 |
|
|
this module, and leave you standing in the rain because we didn't tell |
122 |
|
|
you. |
123 |
|
|
|
124 |
|
|
Most likely, we will pick a few useful warnings, instead of just disabling |
125 |
|
|
all of them. And maybe we will load some nifty modules that try to emulate |
126 |
|
|
C<say> or so with perls older than 5.10 (this module, of course, should |
127 |
|
|
work with older perl versions - supporting 5.8 for example is just common |
128 |
root |
1.6 |
sense at this time. Maybe not in the future, but of course you can trust |
129 |
root |
1.5 |
our common sense). |
130 |
|
|
|
131 |
root |
1.7 |
|
132 |
|
|
=head1 WHAT OTHER PEOPLE HAVE TO SAY ABOUT THIS MODULE |
133 |
|
|
|
134 |
|
|
Pista Palo |
135 |
|
|
|
136 |
|
|
"Something in short supply these days..." |
137 |
|
|
|
138 |
|
|
Steffen Schwigon |
139 |
|
|
|
140 |
|
|
"This module is quite for sure *not* just a repetition of all the other |
141 |
|
|
'use strict, use warnings'-approaches, and it's also not the opposite. |
142 |
|
|
[...] And for its chosen middle-way it's also not the worst name ever. |
143 |
|
|
And everything is documented." |
144 |
|
|
|
145 |
|
|
BKB |
146 |
|
|
|
147 |
|
|
"[Deleted - thanks to Steffen Schwigon for pointing out this review was |
148 |
|
|
in error.]" |
149 |
|
|
|
150 |
|
|
Somni |
151 |
|
|
|
152 |
|
|
"the arrogance of the guy" |
153 |
|
|
"I swear he tacked somenoe else's name onto the module |
154 |
|
|
just so he could use the royal 'we' in the documentation" |
155 |
|
|
|
156 |
|
|
dngor |
157 |
|
|
|
158 |
|
|
"Heh. '"<elmex at ta-sa.org>"' The quotes are semantic |
159 |
|
|
distancing from that e-mail address." |
160 |
|
|
|
161 |
|
|
Jerad Pierce |
162 |
|
|
|
163 |
|
|
"Awful name (not a proper pragma), and the SYNOPSIS doesn't tell you |
164 |
|
|
anything either. Nor is it clear what features have to do with "common |
165 |
|
|
sense" or discipline." |
166 |
|
|
|
167 |
|
|
acme |
168 |
|
|
|
169 |
|
|
"THERE IS NO 'no common::sense'!!!! !!!! !!" |
170 |
|
|
|
171 |
|
|
crab |
172 |
|
|
|
173 |
|
|
"i wonder how it would be if joerg schilling wrote perl modules." |
174 |
|
|
|
175 |
root |
1.8 |
H.Merijn Brand |
176 |
|
|
|
177 |
|
|
"Just one more reason to drop JSON::XS from my distribution list" |
178 |
|
|
|
179 |
root |
1.1 |
=head1 AUTHOR |
180 |
|
|
|
181 |
|
|
Marc Lehmann <schmorp@schmorp.de> |
182 |
|
|
http://home.schmorp.de/ |
183 |
|
|
|
184 |
root |
1.4 |
Robin Redeker, "<elmex at ta-sa.org>". |
185 |
|
|
|
186 |
|
|
|
187 |
root |
1.1 |
=cut |
188 |
|
|
|