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

Comparing common-sense/sense.pm (file contents):
Revision 1.9 by root, Sat Aug 15 14:12:10 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 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	=item use strict qw(subs vars)	53	=item use strict qw(subs vars)
40		54
41	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
42	'refs'> definitely overshoots it's usefulness. After almost two	56	'refs'> definitely overshoots its usefulness. After almost two
43	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
44	useful. Specifically, constructs like these:	58	useful. Specifically, constructs like these:
45		59
46	@{ $var->[0] }	60	@{ $var->[0] }
47		61
…		…
49	scope, and C<$var> can legally be C<undef>:	63	scope, and C<$var> can legally be C<undef>:
50		64
51	@{ $var->[0] \|\| [] }	65	@{ $var->[0] \|\| [] }
52		66
53	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
54	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):
55		70
56	@{ defined $var->[0] ? $var->[0] : [] }	71	@{ defined $var->[0] ? $var->[0] : [] }
57		72
58	... 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
59	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
60	even with C<use strict> in scope:	77	C<use strict> in scope:
61		78
62	for (@{ $var->[0] }) { ...	79	for (@{ $var->[0] }) { ...
63		80
64	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
65		83
66	=item use feature qw(say state given)	84	=item use feature qw(say state given)
67		85
68	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
69	something breaks because it didn't anticipate future changes, so be	87	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	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
71	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
72	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.
73		95
74	If your code isn't alive, it's dead, jim.	96	If your code isn't alive, it's dead, Jim - be an active maintainer.
75		97
76	=item much less memory	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.
77		103
78	Just using all those pragmas together wastes <blink>I<< B<776> kilobytes	104
79	>></blink> of precious memory in my perl, for I<every single perl process	105	=item no warnings, but a lot of new errors
80	using our code>, which on our machines, is a lot. In comparison, this	106
81	module only uses I<< B<four> >> kilobytes (I even had to write it out so	107	Ah, the dreaded warnings. Even worse, the horribly dreaded C<-w>
		108	switch: Even though we don't care if other people use warnings (and
		109	certainly there are useful ones), a lot of warnings simply go against the
		110	spirit of Perl.
		111
		112	Most prominently, the warnings related to C<undef>. There is nothing wrong
		113	with C<undef>: it has well-defined semantics, it is useful, and spitting
		114	out warnings you never asked for is just evil.
		115
		116	The result was that every one of our modules did C<no warnings> in the
		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.
		121
		122	Funnily enough, L<perllexwarn> explicitly mentions C<-w> (and not in a
		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.
		126
		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.
		130
		131	This resulted in the rather impressive list in the SYNOPSIS. When we
		132	weren't sure, we didn't include the warning, so the list might grow in
		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
82	it looks like more) of memory on the same platform.	180	had to write it out so it looks like more) of memory on the same platform.
83		181
84	The money/time/effort/electricity invested in these gigabytes (probably	182	The money/time/effort/electricity invested in these gigabytes (probably
85	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
86	kitten!	184	kitten!
87		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
88	=cut	189	=cut
89		190
90	package common::sense;	191	package common::sense;
91		192
92	our $VERSION = '0.04';	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
93		205
94	sub import {	206	sub import {
95	# no warnings	207	# verified with perl 5.8.0, 5.10.0
96	${^WARNING_BITS} ^= ${^WARNING_BITS};	208	${^WARNING_BITS} ^= ${^WARNING_BITS} ^ "\xfc\x3f\xf3\x00\x0f\xf3\xcf\xc0\xf3\xfc\x33\x03";
97		209
98	# use strict vars subs	210	# use strict vars subs
99	$^H \|= 0x00000600;	211	$^H \|= 0x00000600;
100		212
101	# use feature	213	# use feature
…		…
117	=head1 STABILITY AND FUTURE VERSIONS	229	=head1 STABILITY AND FUTURE VERSIONS
118		230
119	Future versions might change just about everything in this module. We	231	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	232	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	233	this module, and leave you standing in the rain because we didn't tell
122	you.	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.
123		236
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	237	Maybe we will load some nifty modules that try to emulate C<say> or so
126	C<say> or so with perls older than 5.10 (this module, of course, should	238	with perls older than 5.10 (this module, of course, should work with older
127	work with older perl versions - supporting 5.8 for example is just common	239	perl versions - supporting 5.8 for example is just common sense at this
128	sense at this time. Maybe not in the future, but of course you can trust	240	time. Maybe not in the future, but of course you can trust our common
129	our common sense).	241	sense to be consistent with, uhm, our opinion).
130		242
131
132	=head1 WHAT OTHER PEOPLE HAVE TO SAY ABOUT THIS MODULE	243	=head1 WHAT OTHER PEOPLE HAD TO SAY ABOUT THIS MODULE
		244
		245	apeiron
		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"
133		263
134	Pista Palo	264	Pista Palo
135		265
136	"Something in short supply these days..."	266	"Something in short supply these days..."
137		267
…		…
166		296
167	acme	297	acme
168		298
169	"THERE IS NO 'no common::sense'!!!! !!!! !!"	299	"THERE IS NO 'no common::sense'!!!! !!!! !!"
170		300
171	crab	301	apeiron (meta-comment about us commenting^Wquoting his comment)
172		302
173	"i wonder how it would be if joerg schilling wrote perl modules."	303	How about quoting this: get a clue, you fucktarded amoeba.
174		304
175	H.Merijn Brand	305	quanth
176		306
177	"Just one more reason to drop JSON::XS from my distribution list"	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
178		398
179	=head1 AUTHOR	399	=head1 AUTHOR
180		400
181	Marc Lehmann <schmorp@schmorp.de>	401	Marc Lehmann <schmorp@schmorp.de>
182	http://home.schmorp.de/	402	http://home.schmorp.de/
183		403
184	Robin Redeker, "<elmex at ta-sa.org>".	404	Robin Redeker, "<elmex at ta-sa.org>".
185		405
186
187	=cut	406	=cut
188		407

Diff Legend

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

Comparing common-sense/sense.pm (file contents): Revision 1.9 by root, Sat Aug 15 14:12:10 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.9 by root, Sat Aug 15 14:12:10 2009 UTC vs.
Revision 1.22 by root, Wed Nov 4 11:04:25 2009 UTC