… | |
… | |
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 | 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 | |
23 | =item use strict qw(subs vars) |
39 | =item use strict qw(subs vars) |
24 | |
40 | |
25 | Using C<use strict> is definitely common sense, but C<use strict |
41 | Using C<use strict> is definitely common sense, but C<use strict |
26 | 'refs'> definitely overshoots it's usefulness. After almost two |
42 | 'refs'> definitely overshoots it's usefulness. After almost two |
27 | decades of Perl hacking, we decided that it does more harm than being |
43 | decades of Perl hacking, we decided that it does more harm than being |
28 | useful. Specifically, constructs like these: |
44 | useful. Specifically, constructs like these: |
29 | |
45 | |
30 | @{ $var->[0] } |
46 | @{ $var->[0] } |
31 | |
47 | |
32 | Must be written like this, when C<use strict 'refs'> is in scope, and |
48 | Must be written like this (or similarly), when C<use strict 'refs'> is in |
33 | C<$var> can legally be C<undef>: |
49 | scope, and C<$var> can legally be C<undef>: |
34 | |
50 | |
35 | @{ $var->[0] || [] } |
51 | @{ $var->[0] || [] } |
36 | |
52 | |
37 | This is annoying, and doesn't shield against obvious mistakes such as |
53 | This is annoying, and doesn't shield against obvious mistakes such as |
38 | using C<"">, so one would even have to write: |
54 | using C<"">, so one would even have to write: |
… | |
… | |
53 | something breaks because it didn't anticipate future changes, so be |
69 | 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 |
70 | it. 5.10 broke almost all our XS modules and nobody cared either - and few |
55 | modules that are no longer maintained work with newer versions of Perl, |
71 | modules that are no longer maintained work with newer versions of Perl, |
56 | regardless of use feature. |
72 | regardless of use feature. |
57 | |
73 | |
58 | If your code isn'talive, it's dead, jim. |
74 | If your code isn't alive, it's dead, jim. |
59 | |
|
|
60 | =item no warnings |
|
|
61 | |
|
|
62 | The dreaded warnings. Even worse, the horribly dreaded C<-w> switch. Even |
|
|
63 | though we don't care if other people use warnings (and certainly there are |
|
|
64 | useful ones), a lot of warnings simply go against the spirit of Perl, most |
|
|
65 | prominently, the warnings related to C<undef>. There is nothing wrong with |
|
|
66 | C<undef>: it has well-defined semantics, it is useful, and spitting out |
|
|
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 | |
75 | =item much less memory |
76 | =item much less memory |
76 | |
77 | |
77 | Just using all those pragmas together waste <blink>I<< B<776> kilobytes |
78 | 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 | >></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 | 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. |
80 | |
83 | |
81 | The money/time/effort/electricity invested in these gigabytes (probably |
84 | The money/time/effort/electricity invested in these gigabytes (probably |
82 | petabytes globally!) of wasted memory could easily save 42 trees, and a |
85 | petabytes globally!) of wasted memory could easily save 42 trees, and a |
83 | kitten! |
86 | kitten! |
84 | |
87 | |
… | |
… | |
87 | package common::sense; |
90 | package common::sense; |
88 | |
91 | |
89 | our $VERSION = '0.03'; |
92 | our $VERSION = '0.03'; |
90 | |
93 | |
91 | sub import { |
94 | sub import { |
|
|
95 | # no warnings |
92 | ${^WARNING_BITS} ^= ${^WARNING_BITS}; |
96 | ${^WARNING_BITS} ^= ${^WARNING_BITS}; |
|
|
97 | |
|
|
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; |
93 | } |
105 | } |
94 | |
|
|
95 | =cut |
|
|
96 | |
106 | |
97 | 1; |
107 | 1; |
98 | |
108 | |
99 | =back |
109 | =back |
100 | |
110 | |
101 | =head1 EXAMPLE |
111 | =head1 THERE IS NO 'no common::sense'!!!! !!!! !! |
102 | |
112 | |
103 | There really should be a complete C/XS example. Bug me about it. |
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? |
104 | |
116 | |
105 | =head1 IMPLEMENTATION DETAILS AND LIMITATIONS |
117 | =head1 STABILITY AND FUTURE VERSIONS |
106 | |
118 | |
107 | This module works by "hijacking" SIGKILL, which is guaranteed to be always |
119 | Future versions might change just about everything in this module. We |
108 | available in perl, but also cannot be caught, so is always available. |
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. |
109 | |
123 | |
110 | Basically, this module fakes the receive of a SIGKILL signal and |
124 | Most likely, we will pick a few useful warnings, instead of just disabling |
111 | then catches it. This makes normal signal handling slower (probably |
125 | all of them. And maybe we will load some nifty modules that try to emulate |
112 | unmeasurably), but has the advantage of not requiring a special runops nor |
126 | C<say> or so with perls older than 5.10 (this module, of course, should |
113 | slowing down normal perl execution a bit. |
127 | work with older perl versions - supporting 5.8 for example is just common |
114 | |
128 | sense at this time. Maybe not in the future, but of course you cna trust |
115 | It assumes that C<sig_atomic_t> and C<int> are both exception-safe to |
129 | our common sense). |
116 | modify (C<sig_atomic_> is used by this module, and perl itself uses |
|
|
117 | C<int>, so we can assume that this is quite portable, at least w.r.t. |
|
|
118 | signals). |
|
|
119 | |
130 | |
120 | =head1 AUTHOR |
131 | =head1 AUTHOR |
121 | |
132 | |
122 | Marc Lehmann <schmorp@schmorp.de> |
133 | Marc Lehmann <schmorp@schmorp.de> |
123 | http://home.schmorp.de/ |
134 | http://home.schmorp.de/ |
124 | |
135 | |
|
|
136 | Robin Redeker, "<elmex at ta-sa.org>". |
|
|
137 | |
|
|
138 | |
125 | =cut |
139 | =cut |
126 | |
140 | |