… | |
… | |
18 | two typical (or not so typical - use your common sense) specimens of |
18 | two typical (or not so typical - use your common sense) specimens of |
19 | Perl coders. |
19 | Perl coders. |
20 | |
20 | |
21 | =over 4 |
21 | =over 4 |
22 | |
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 | |
23 | =item use strict qw(subs vars) |
42 | =item use strict qw(subs vars) |
24 | |
43 | |
25 | Using C<use strict> is definitely common sense, but C<use strict |
44 | Using C<use strict> is definitely common sense, but C<use strict |
26 | 'refs'> definitely overshoots it's usefulness. After almost two |
45 | 'refs'> definitely overshoots its usefulness. After almost two |
27 | decades of Perl hacking, we decided that it does more harm than being |
46 | decades of Perl hacking, we decided that it does more harm than being |
28 | useful. Specifically, constructs like these: |
47 | useful. Specifically, constructs like these: |
29 | |
48 | |
30 | @{ $var->[0] } |
49 | @{ $var->[0] } |
31 | |
50 | |
32 | Must be written like this, when C<use strict 'refs'> is in scope, and |
51 | Must be written like this (or similarly), when C<use strict 'refs'> is in |
33 | C<$var> can legally be C<undef>: |
52 | scope, and C<$var> can legally be C<undef>: |
34 | |
53 | |
35 | @{ $var->[0] || [] } |
54 | @{ $var->[0] || [] } |
36 | |
55 | |
37 | This is annoying, and doesn't shield against obvious mistakes such as |
56 | This is annoying, and doesn't shield against obvious mistakes such as |
38 | using C<"">, so one would even have to write: |
57 | using C<"">, so one would even have to write (at least for the time |
|
|
58 | being): |
39 | |
59 | |
40 | @{ defined $var->[0] ? $var->[0] : [] } |
60 | @{ defined $var->[0] ? $var->[0] : [] } |
41 | |
61 | |
42 | ... which nobody with a bit of common sense would consider |
62 | ... which nobody with a bit of common sense would consider |
|
|
63 | writing. |
|
|
64 | |
43 | writing. Curiously enough, sometimes, perl is not so strict, as this works |
65 | Curiously enough, sometimes perl is not so strict, as this works even with |
44 | even with C<use strict> in scope: |
66 | C<use strict> in scope: |
45 | |
67 | |
46 | for (@{ $var->[0] }) { ... |
68 | for (@{ $var->[0] }) { ... |
47 | |
69 | |
48 | If that isnt hipocrasy! And all that from a mere program! |
70 | If that isn't hipocrasy! And all that from a mere program! |
49 | |
71 | |
50 | =item use feature qw(say state given) |
72 | =item use feature qw(say state given) |
51 | |
73 | |
52 | We found it annoying that we always have to enable extra features. If |
74 | We found it annoying that we always have to enable extra features. If |
53 | something breaks because it didn't anticipate future changes, so be |
75 | something breaks because it didn't anticipate future changes, so be |
54 | it. 5.10 broke almost all our XS modules and nobody cared either - and few |
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 | |
55 | modules that are no longer maintained work with newer versions of Perl, |
80 | Few modules that are not actively maintained work with newer versions of |
56 | regardless of use feature. |
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. |
57 | |
83 | |
58 | If your code isn'talive, it's dead, jim. |
84 | If your code isn't alive, it's dead, jim - be an active maintainer. |
59 | |
85 | |
60 | =item no warnings |
86 | =item mucho reduced memory usage |
61 | |
87 | |
62 | The dreaded warnings. Even worse, the horribly dreaded C<-w> switch. Even |
88 | Just using all those pragmas mentioned in the SYNOPSIS together wastes |
63 | though we don't care if other people use warnings (and certainly there are |
89 | <blink>I<< B<776> kilobytes >></blink> of precious memory in my perl, for |
64 | useful ones), a lot of warnings simply go against the spirit of Perl, most |
90 | I<every single perl process using our code>, which on our machines, is a |
65 | prominently, the warnings related to C<undef>. There is nothing wrong with |
91 | lot. In comparison, this module only uses I<< B<four> >> kilobytes (I even |
66 | C<undef>: it has well-defined semantics, it is useful, and spitting out |
92 | had to write it out so it looks like more) of memory on the same platform. |
67 | warnings you never asked for is just evil. |
|
|
68 | |
|
|
69 | So every module needs C<no warnings> to avoid somebody accidentally using |
|
|
70 | C<-w> and forcing his bad standards on our code. No will do. |
|
|
71 | |
|
|
72 | (Also, why isn't this a C<use feature> switch? Adding warnings is |
|
|
73 | apparently considered O.K., even if it breaks your programs). |
|
|
74 | |
|
|
75 | =item much less memory |
|
|
76 | |
|
|
77 | Just using all those pragmas together waste <blink>I<< B<776> kilobytes |
|
|
78 | >></blink> of precious memory in my perl, for I<every single perl process |
|
|
79 | using our code>, which on our machines, is a lot. |
|
|
80 | |
93 | |
81 | The money/time/effort/electricity invested in these gigabytes (probably |
94 | The money/time/effort/electricity invested in these gigabytes (probably |
82 | petabytes globally!) of wasted memory could easily save 42 trees, and a |
95 | petabytes globally!) of wasted memory could easily save 42 trees, and a |
83 | kitten! |
96 | kitten! |
84 | |
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 | |
85 | =cut |
101 | =cut |
86 | |
102 | |
87 | package Async::Interrupt; |
103 | package common::sense; |
88 | |
104 | |
|
|
105 | our $VERSION = '1.0'; |
|
|
106 | |
89 | no warnings; |
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} }; |
90 | |
112 | |
91 | BEGIN { |
113 | # overload should be included |
92 | $VERSION = '0.03'; |
|
|
93 | |
114 | |
94 | require XSLoader; |
115 | sub import { |
95 | XSLoader::load Async::Interrupt::, $VERSION; |
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; |
96 | } |
126 | } |
97 | |
127 | |
98 | our $DIED = sub { warn "$@" }; |
|
|
99 | |
|
|
100 | =cut |
|
|
101 | |
|
|
102 | 1; |
128 | 1; |
103 | |
129 | |
104 | =back |
130 | =back |
105 | |
131 | |
106 | =head1 EXAMPLE |
132 | =head1 THERE IS NO 'no common::sense'!!!! !!!! !! |
107 | |
133 | |
108 | There really should be a complete C/XS example. Bug me about it. |
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? |
109 | |
137 | |
110 | =head1 IMPLEMENTATION DETAILS AND LIMITATIONS |
138 | =head1 STABILITY AND FUTURE VERSIONS |
111 | |
139 | |
112 | This module works by "hijacking" SIGKILL, which is guaranteed to be always |
140 | Future versions might change just about everything in this module. We |
113 | available in perl, but also cannot be caught, so is always available. |
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. |
114 | |
144 | |
115 | Basically, this module fakes the receive of a SIGKILL signal and |
145 | Most likely, we will pick a few useful warnings, instead of just disabling |
116 | then catches it. This makes normal signal handling slower (probably |
146 | all of them. And maybe we will load some nifty modules that try to emulate |
117 | unmeasurably), but has the advantage of not requiring a special runops nor |
147 | C<say> or so with perls older than 5.10 (this module, of course, should |
118 | slowing down normal perl execution a bit. |
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). |
119 | |
151 | |
120 | It assumes that C<sig_atomic_t> and C<int> are both exception-safe to |
152 | =head1 WHAT OTHER PEOPLE HAD TO SAY ABOUT THIS MODULE |
121 | modify (C<sig_atomic_> is used by this module, and perl itself uses |
153 | |
122 | C<int>, so we can assume that this is quite portable, at least w.r.t. |
154 | apeiron |
123 | signals). |
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. |
124 | |
207 | |
125 | =head1 AUTHOR |
208 | =head1 AUTHOR |
126 | |
209 | |
127 | Marc Lehmann <schmorp@schmorp.de> |
210 | Marc Lehmann <schmorp@schmorp.de> |
128 | http://home.schmorp.de/ |
211 | http://home.schmorp.de/ |
129 | |
212 | |
|
|
213 | Robin Redeker, "<elmex at ta-sa.org>". |
|
|
214 | |
130 | =cut |
215 | =cut |
131 | |
216 | |