[ViewVC] Diff of: cvs/common-sense/sense.pm

Comparing common-sense/sense.pm (file contents):
Revision 1.2 by root, Thu Jul 9 17:25:48 2009 UTC vs.
Revision 1.22 by root, Wed Nov 4 11:04:25 2009 UTC

…		…
4		4
5	=head1 SYNOPSIS	5	=head1 SYNOPSIS
6		6
7	use common::sense;	7	use common::sense;
8		8
9	# roughly the same as, with much lower memory usage:	9	# supposed to be the same, with much lower memory usage, as:
10	#	10	#
11	# use strict qw(vars subs);	11	# use strict qw(vars subs);
12	# use feature qw(say state switch);	12	# use feature qw(say state switch);
13	# no warnings;	13	# no warnings;
		14	# use warnings qw(FATAL closed threads internal debugging pack substr malloc
		15	# unopened portable prototype inplace io pipe unpack regexp
		16	# deprecated exiting glob digit printf utf8 layer
		17	# reserved parenthesis taint closure semicolon);
		18	# no warnings qw(exec newline);
14		19
15	=head1 DESCRIPTION	20	=head1 DESCRIPTION
16		21
17	This module implements some sane defaults for Perl programs, as defined by	22	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	23	two typical (or not so typical - use your common sense) specimens of Perl
19	Perl coders.	24	coders. In fact, after working out details on which warnings and strict
		25	modes to enable and make fatal, we found that we (and our code written so
		26	far, and others) fully agree on every option, even though we never used
		27	warnings before, so it seems this module indeed reflects a "common" sense
		28	among some long-time Perl coders.
		29
		30	The basic philosophy behind the choices made in common::sense can be
		31	summarised as: "enforcing strict policies to catch as many bugs as
		32	possible, while at the same time, not limiting the expressive power
		33	available to the programmer".
		34
		35	Two typical examples of this philosophy are uninitialised and malloc
		36	warnings:
		37
		38	C<undef> is a well-defined feature of perl, and enabling warnings for
		39	using it rarely catches any bugs, but considerably limits you in what you
		40	can do, so uninitialised warnings are disabled.
		41
		42	Freeing something twice on the C level is a serious bug, usually causing
		43	memory corruption. It often leads to side effects much later in the
		44	program and there are no advantages to not reporting this, so malloc
		45	warnings are fatal by default.
		46
		47	What follows is a more thorough discussion of what this module does,
		48	and why it does it, and what the advantages (and disadvantages) of this
		49	approach are.
20		50
21	=over 4	51	=over 4
22		52
23	=item use strict qw(subs vars)	53	=item use strict qw(subs vars)
24		54
25	Using C<use strict> is definitely common sense, but C<use strict	55	Using C<use strict> is definitely common sense, but C<use strict
26	'refs'> definitely overshoots it's usefulness. After almost two	56	'refs'> definitely overshoots its usefulness. After almost two
27	decades of Perl hacking, we decided that it does more harm than being	57	decades of Perl hacking, we decided that it does more harm than being
28	useful. Specifically, constructs like these:	58	useful. Specifically, constructs like these:
29		59
30	@{ $var->[0] }	60	@{ $var->[0] }
31		61
32	Must be written like this, when C<use strict 'refs'> is in scope, and	62	Must be written like this (or similarly), when C<use strict 'refs'> is in
33	C<$var> can legally be C<undef>:	63	scope, and C<$var> can legally be C<undef>:
34		64
35	@{ $var->[0] \|\| [] }	65	@{ $var->[0] \|\| [] }
36		66
37	This is annoying, and doesn't shield against obvious mistakes such as	67	This is annoying, and doesn't shield against obvious mistakes such as
38	using C<"">, so one would even have to write:	68	using C<"">, so one would even have to write (at least for the time
		69	being):
39		70
40	@{ defined $var->[0] ? $var->[0] : [] }	71	@{ defined $var->[0] ? $var->[0] : [] }
41		72
42	... which nobody with a bit of common sense would consider	73	... which nobody with a bit of common sense would consider
		74	writing: clear code is clearly something else.
		75
43	writing. Curiously enough, sometimes, perl is not so strict, as this works	76	Curiously enough, sometimes perl is not so strict, as this works even with
44	even with C<use strict> in scope:	77	C<use strict> in scope:
45		78
46	for (@{ $var->[0] }) { ...	79	for (@{ $var->[0] }) { ...
47		80
48	If that isnt hipocrasy! And all that from a mere program!	81	If that isn't hypocrisy! And all that from a mere program!
		82
49		83
50	=item use feature qw(say state given)	84	=item use feature qw(say state given)
51		85
52	We found it annoying that we always have to enable extra features. If	86	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	87	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	88	it. 5.10 broke almost all our XS modules and nobody cared either (or at
		89	least I know of nobody who really complained about gratuitous changes -
		90	as opposed to bugs).
		91
55	modules that are no longer maintained work with newer versions of Perl,	92	Few modules that are not actively maintained work with newer versions of
56	regardless of use feature.	93	Perl, regardless of use feature or not, so a new major perl release means
		94	changes to many modules - new keywords are just the tip of the iceberg.
57		95
58	If your code isn'talive, it's dead, jim.	96	If your code isn't alive, it's dead, Jim - be an active maintainer.
59		97
60	=item no warnings	98	But nobody forces you to use those extra features in modules meant for
		99	older versions of perl - common::sense of course works there as well.
		100	There is also an important other mode where having additional features by
		101	default is useful: commandline hacks and internal use scripts: See "much
		102	reduced typing", below.
61		103
		104
		105	=item no warnings, but a lot of new errors
		106
62	The dreaded warnings. Even worse, the horribly dreaded C<-w> switch. Even	107	Ah, the dreaded warnings. Even worse, the horribly dreaded C<-w>
63	though we don't care if other people use warnings (and certainly there are	108	switch: Even though we don't care if other people use warnings (and
64	useful ones), a lot of warnings simply go against the spirit of Perl, most	109	certainly there are useful ones), a lot of warnings simply go against the
		110	spirit of Perl.
		111
65	prominently, the warnings related to C<undef>. There is nothing wrong with	112	Most prominently, the warnings related to C<undef>. There is nothing wrong
66	C<undef>: it has well-defined semantics, it is useful, and spitting out	113	with C<undef>: it has well-defined semantics, it is useful, and spitting
67	warnings you never asked for is just evil.	114	out warnings you never asked for is just evil.
68		115
69	So every module needs C<no warnings> to avoid somebody accidentally using	116	The result was that every one of our modules did C<no warnings> in the
70	C<-w> and forcing his bad standards on our code. No will do.	117	past, to avoid somebody accidentally using and forcing his bad standards
		118	on our code. Of course, this switched off all warnings, even the useful
		119	ones. Not a good situation. Really, the C<-w> switch should only enable
		120	warnings for the main program only.
71		121
72	(Also, why isn't this a C<use feature> switch? Adding warnings is	122	Funnily enough, L<perllexwarn> explicitly mentions C<-w> (and not in a
73	apparently considered O.K., even if it breaks your programs).	123	favourable way, calling it outright "wrong"), but standard utilities, such
		124	as L<prove>, or MakeMaker when running C<make test>, still enable them
		125	blindly.
74		126
75	=item much less memory	127	For version 2 of common::sense, we finally sat down a few hours and went
		128	through I<every single warning message>, identifiying - according to
		129	common sense - all the useful ones.
76		130
77	Just using all those pragmas together waste <blink>I<< B<776> kilobytes	131	This resulted in the rather impressive list in the SYNOPSIS. When we
78	>></blink> of precious memory in my perl, for I<every single perl process	132	weren't sure, we didn't include the warning, so the list might grow in
79	using our code>, which on our machines, is a lot.	133	the future (we might have made a mistake, too, so the list might shrink
		134	as well).
		135
		136	Note the presence of C<FATAL> in the list: we do not think that the
		137	conditions caught by these warnings are worthy of a warning, we I<insist>
		138	that they are worthy of I<stopping> your program, I<instantly>. They are
		139	I<bugs>!
		140
		141	Therefore we consider C<common::sense> to be much stricter than C<use
		142	warnings>, which is good if you are into strict things (we are not,
		143	actually, but these things tend to be subjective).
		144
		145	After deciding on the list, we ran the module against all of our code that
		146	uses C<common::sense> (that is almost all of our code), and found only one
		147	occurence where one of them caused a problem: one of elmex's (unreleased)
		148	modules contained:
		149
		150	$fmt =~ s/([^\s\[])\[( [^\]] )\]/\x0$1\x1$2\x0/xgo;
		151
		152	We quickly agreed that indeed the code should be changed, even though it
		153	happened to do the right thing when the warning was switched off.
		154
		155
		156	=item much reduced typing
		157
		158	Especially with version 2.0 of common::sense, the amount of boilerplate
		159	code you need to add to gte I<this> policy is daunting. Nobody would write
		160	this out in throwaway scripts, commandline hacks or in quick internal-use
		161	scripts.
		162
		163	By using common::sense you get a defined set of policies (ours, but maybe
		164	yours, too, if you accept them), and they are easy to apply to your
		165	scripts: typing C<use common::sense;> is even shorter than C<use warnings;
		166	use strict; use feature ...>.
		167
		168	And you can immediately use the features of your installed perl, which
		169	is more difficult in code you release, but not usually an issue for
		170	internal-use code (downgrades of your production perl should be rare,
		171	right?).
		172
		173
		174	=item mucho reduced memory usage
		175
		176	Just using all those pragmas mentioned in the SYNOPSIS together wastes
		177	<blink>I<< B<776> kilobytes >></blink> of precious memory in my perl, for
		178	I<every single perl process using our code>, which on our machines, is a
		179	lot. In comparison, this module only uses I<< B<four> >> kilobytes (I even
		180	had to write it out so it looks like more) of memory on the same platform.
80		181
81	The money/time/effort/electricity invested in these gigabytes (probably	182	The money/time/effort/electricity invested in these gigabytes (probably
82	petabytes globally!) of wasted memory could easily save 42 trees, and a	183	petabytes globally!) of wasted memory could easily save 42 trees, and a
83	kitten!	184	kitten!
84		185
		186	Unfortunately, until everybods applies more common sense, there will still
		187	often be modules that pull in the monster pragmas. But one can hope...
		188
85	=cut	189	=cut
86		190
87	package common::sense;	191	package common::sense;
88		192
89	our $VERSION = '0.03';	193	our $VERSION = '2.02';
		194
		195	# paste this into perl to find bitmask
		196
		197	# no warnings;
		198	# use warnings qw(FATAL closed threads internal debugging pack substr malloc unopened portable prototype
		199	# inplace io pipe unpack regexp deprecated exiting glob digit printf
		200	# utf8 layer reserved parenthesis taint closure semicolon);
		201	# no warnings qw(exec newline);
		202	# BEGIN { warn join "", map "\\x$_", unpack "(H2)*", ${^WARNING_BITS}; exit 0 };
		203
		204	# overload should be included
90		205
91	sub import {	206	sub import {
92	${^WARNING_BITS} ^= ${^WARNING_BITS};	207	# verified with perl 5.8.0, 5.10.0
		208	${^WARNING_BITS} ^= ${^WARNING_BITS} ^ "\xfc\x3f\xf3\x00\x0f\xf3\xcf\xc0\xf3\xfc\x33\x03";
		209
		210	# use strict vars subs
		211	$^H \|= 0x00000600;
		212
		213	# use feature
		214	$^H{feature_switch} =
		215	$^H{feature_say} =
		216	$^H{feature_state} = 1;
93	}	217	}
94		218
95	=cut
96
97	1;	219	1;
98		220
99	=back	221	=back
100		222
101	=head1 EXAMPLE	223	=head1 THERE IS NO 'no common::sense'!!!! !!!! !!
102		224
103	There really should be a complete C/XS example. Bug me about it.	225	This module doesn't offer an unimport. First of all, it wastes even more
		226	memory, second, and more importantly, who with even a bit of common sense
		227	would want no common sense?
104		228
105	=head1 IMPLEMENTATION DETAILS AND LIMITATIONS	229	=head1 STABILITY AND FUTURE VERSIONS
106		230
107	This module works by "hijacking" SIGKILL, which is guaranteed to be always	231	Future versions might change just about everything in this module. We
108	available in perl, but also cannot be caught, so is always available.	232	might test our modules and upload new ones working with newer versions of
		233	this module, and leave you standing in the rain because we didn't tell
		234	you. In fact, we did so when switching from 1.0 to 2.0, which enabled gobs
		235	of warnings, and made them FATAL on top.
109		236
110	Basically, this module fakes the receive of a SIGKILL signal and	237	Maybe we will load some nifty modules that try to emulate C<say> or so
111	then catches it. This makes normal signal handling slower (probably	238	with perls older than 5.10 (this module, of course, should work with older
112	unmeasurably), but has the advantage of not requiring a special runops nor	239	perl versions - supporting 5.8 for example is just common sense at this
113	slowing down normal perl execution a bit.	240	time. Maybe not in the future, but of course you can trust our common
		241	sense to be consistent with, uhm, our opinion).
114		242
115	It assumes that C<sig_atomic_t> and C<int> are both exception-safe to	243	=head1 WHAT OTHER PEOPLE HAD TO SAY ABOUT THIS MODULE
116	modify (C<sig_atomic_> is used by this module, and perl itself uses	244
117	C<int>, so we can assume that this is quite portable, at least w.r.t.	245	apeiron
118	signals).	246
		247	"... wow"
		248	"I hope common::sense is a joke."
		249
		250	crab
		251
		252	"i wonder how it would be if joerg schilling wrote perl modules."
		253
		254	Adam Kennedy
		255
		256	"Very interesting, efficient, and potentially something I'd use all the time."
		257	[...]
		258	"So no common::sense for me, alas."
		259
		260	H.Merijn Brand
		261
		262	"Just one more reason to drop JSON::XS from my distribution list"
		263
		264	Pista Palo
		265
		266	"Something in short supply these days..."
		267
		268	Steffen Schwigon
		269
		270	"This module is quite for sure not just a repetition of all the other
		271	'use strict, use warnings'-approaches, and it's also not the opposite.
		272	[...] And for its chosen middle-way it's also not the worst name ever.
		273	And everything is documented."
		274
		275	BKB
		276
		277	"[Deleted - thanks to Steffen Schwigon for pointing out this review was
		278	in error.]"
		279
		280	Somni
		281
		282	"the arrogance of the guy"
		283	"I swear he tacked somenoe else's name onto the module
		284	just so he could use the royal 'we' in the documentation"
		285
		286	dngor
		287
		288	"Heh. '"<elmex at ta-sa.org>"' The quotes are semantic
		289	distancing from that e-mail address."
		290
		291	Jerad Pierce
		292
		293	"Awful name (not a proper pragma), and the SYNOPSIS doesn't tell you
		294	anything either. Nor is it clear what features have to do with "common
		295	sense" or discipline."
		296
		297	acme
		298
		299	"THERE IS NO 'no common::sense'!!!! !!!! !!"
		300
		301	apeiron (meta-comment about us commenting^Wquoting his comment)
		302
		303	How about quoting this: get a clue, you fucktarded amoeba.
		304
		305	quanth
		306
		307	common sense is beautiful, json::xs is fast, Anyevent, EV are fast and
		308	furious. I love mlehmannware ;)
		309
		310	=head1 FREQUQNTLY ASKED QUESTIONS
		311
		312	Or frequently-come-up confusions.
		313
		314	=over 4
		315
		316	=item Is this module meant to be serious?
		317
		318	Yes, we would have put it under the C<Acme::> namespace otherwise.
		319
		320	=item But the manpage is written in a funny/stupid/... way?
		321
		322	This was meant to make it clear that our common sense is a subjective
		323	thing and other people can use their own notions, taking the steam out
		324	of anybody who might be offended (as some people are always offended no
		325	matter what you do).
		326
		327	This was a failure.
		328
		329	But we hope the manpage still is somewhat entertaining even though it
		330	explains boring rationale.
		331
		332	=item Why do you impose your conventions on my code?
		333
		334	For some reason people keep thinking that C<common::sense> imposes
		335	process-wide limits, even though the SYNOPSIS makes it clear that it works
		336	like other similar modules - only on the scope that uses them.
		337
		338	So, no, we don't - nobody is forced to use this module, and using a module
		339	that relies on common::sense does not impose anything on you.
		340
		341	=item Why do you think only your notion of common::sense is valid?
		342
		343	Well, we don't, and have clearly written this in the documentation to
		344	every single release. We were just faster than anybody else w.r.t. to
		345	grabbing the namespace.
		346
		347	=item But everybody knows that you have to use strict and use warnings,
		348	why do you disable them?
		349
		350	Well, we don't do this either - we selectively disagree with the
		351	usefulness of some warnings over others. This module is aimed at
		352	experienced Perl programmers, not people migrating from other languages
		353	who might be surprised about stuff such as C<undef>. On the other hand,
		354	this does not exclude the usefulness of this module for total newbies, due
		355	to its strictness in enforcing policy, while at the same time not limiting
		356	the expresive power of perl.
		357
		358	This module is considerably I<more> strict than the canonical C<use
		359	strict; use warnings>, as it makes all its warnings fatal in nature, so
		360	you can not get away with as many things as with the canonical approach.
		361
		362	This was not implemented in version 1.0 because of the daunting number
		363	of warning categories and the difficulty in getting exactly the set of
		364	warnings you wish (i.e. look at the SYNOPSIS in how complicated it is to
		365	get a specific set of warnings - it is not reasonable to put this into
		366	every module, the maintainance effort would be enourmous).
		367
		368	=item But many modules C<use strict> or C<use warnings>, so the memory
		369	savings do not apply?
		370
		371	I am suddenly so sad.
		372
		373	But yes, that's true. Fortunately C<common::sense> still uses only a
		374	miniscule amount of RAM.
		375
		376	=item But it adds another dependency to your modules!
		377
		378	It's a fact, yeah. But it's trivial to install, most popular modules have
		379	many more dependencies and we consider dependencies a good thing - it
		380	leads to better APIs, more thought about interworking of modules and so
		381	on.
		382
		383	=item Why do you use JSON and not YAML for your META.yml?
		384
		385	This is not true - YAML supports a large subset of JSON, and this subset
		386	is what META.yml is written in, so it would be correct to say "the
		387	META.yml is written in a common subset of YAML and JSON".
		388
		389	The META.yml follows the YAML, JSON and META.yml specifications, and is
		390	correctly parsed by CPAN, so if you have trouble with it, the problem is
		391	likely on your side.
		392
		393	=item But! But!
		394
		395	Yeah, we know.
		396
		397	=back
119		398
120	=head1 AUTHOR	399	=head1 AUTHOR
121		400
122	Marc Lehmann <schmorp@schmorp.de>	401	Marc Lehmann <schmorp@schmorp.de>
123	http://home.schmorp.de/	402	http://home.schmorp.de/
124		403
		404	Robin Redeker, "<elmex at ta-sa.org>".
		405
125	=cut	406	=cut
126		407

Diff Legend

-–
+Removed lines
-+
+Added lines
-<
+Changed lines
->
+Changed lines

Comparing common-sense/sense.pm (file contents): Revision 1.2 by root, Thu Jul 9 17:25:48 2009 UTC vs. Revision 1.22 by root, Wed Nov 4 11:04:25 2009 UTC

Diff Legend

Comparing common-sense/sense.pm (file contents):
Revision 1.2 by root, Thu Jul 9 17:25:48 2009 UTC vs.
Revision 1.22 by root, Wed Nov 4 11:04:25 2009 UTC