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

Comparing common-sense/sense.pm (file contents):
Revision 1.11 by root, Sat Aug 22 20:21:29 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	53	=item use strict qw(subs vars)
		54
		55	Using C<use strict> is definitely common sense, but C<use strict
		56	'refs'> definitely overshoots its usefulness. After almost two
		57	decades of Perl hacking, we decided that it does more harm than being
		58	useful. Specifically, constructs like these:
		59
		60	@{ $var->[0] }
		61
		62	Must be written like this (or similarly), when C<use strict 'refs'> is in
		63	scope, and C<$var> can legally be C<undef>:
		64
		65	@{ $var->[0] \|\| [] }
		66
		67	This is annoying, and doesn't shield against obvious mistakes such as
		68	using C<"">, so one would even have to write (at least for the time
		69	being):
		70
		71	@{ defined $var->[0] ? $var->[0] : [] }
		72
		73	... which nobody with a bit of common sense would consider
		74	writing: clear code is clearly something else.
		75
		76	Curiously enough, sometimes perl is not so strict, as this works even with
		77	C<use strict> in scope:
		78
		79	for (@{ $var->[0] }) { ...
		80
		81	If that isn't hypocrisy! And all that from a mere program!
		82
		83
		84	=item use feature qw(say state given)
		85
		86	We found it annoying that we always have to enable extra features. If
		87	something breaks because it didn't anticipate future changes, so be
		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
		92	Few modules that are not actively maintained work with newer versions of
		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.
		95
		96	If your code isn't alive, it's dead, Jim - be an active maintainer.
		97
		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.
		103
		104
		105	=item no warnings, but a lot of new errors
24		106
25	Ah, the dreaded warnings. Even worse, the horribly dreaded C<-w>	107	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	108	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	109	certainly there are useful ones), a lot of warnings simply go against the
28	spirit of Perl.	110	spirit of Perl.
29		111
30	Most prominently, the warnings related to C<undef>. There is nothing wrong	112	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	113	with C<undef>: it has well-defined semantics, it is useful, and spitting
32	out warnings you never asked for is just evil.	114	out warnings you never asked for is just evil.
33		115
34	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
35	C<-w> and forcing his bad standards on our code. No will do. Really, the	117	past, to avoid somebody accidentally using and forcing his bad standards
36	C<-w> switch should only enable wanrings for the main program.	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.
37		121
38	Funnily enough, L<perllexwarn> explicitly mentions C<-w> (and not in a	122	Funnily enough, L<perllexwarn> explicitly mentions C<-w> (and not in a
39	favourable way), but standard utilities, such as L<prove>, or MakeMaker	123	favourable way, calling it outright "wrong"), but standard utilities, such
40	when running C<make test> enable them blindly.	124	as L<prove>, or MakeMaker when running C<make test>, still enable them
		125	blindly.
41		126
42	=item use strict qw(subs vars)	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.
43		130
44	Using C<use strict> is definitely common sense, but C<use strict	131	This resulted in the rather impressive list in the SYNOPSIS. When we
45	'refs'> definitely overshoots its usefulness. After almost two	132	weren't sure, we didn't include the warning, so the list might grow in
46	decades of Perl hacking, we decided that it does more harm than being	133	the future (we might have made a mistake, too, so the list might shrink
47	useful. Specifically, constructs like these:	134	as well).
48		135
49	@{ $var->[0] }	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>!
50		140
51	Must be written like this (or similarly), when C<use strict 'refs'> is in	141	Therefore we consider C<common::sense> to be much stricter than C<use
52	scope, and C<$var> can legally be C<undef>:	142	warnings>, which is good if you are into strict things (we are not,
		143	actually, but these things tend to be subjective).
53		144
54	@{ $var->[0] \|\| [] }	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:
55		149
56	This is annoying, and doesn't shield against obvious mistakes such as	150	$fmt =~ s/([^\s\[])\[( [^\]] )\]/\x0$1\x1$2\x0/xgo;
57	using C<"">, so one would even have to write (at least for the time
58	being):
59		151
60	@{ defined $var->[0] ? $var->[0] : [] }	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.
61		154
62	... which nobody with a bit of common sense would consider
63	writing.
64		155
65	Curiously enough, sometimes perl is not so strict, as this works even with	156	=item much reduced typing
66	C<use strict> in scope:
67		157
68	for (@{ $var->[0] }) { ...	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.
69		162
70	If that isn't hipocrasy! And all that from a mere program!	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 ...>.
71		167
72	=item use feature qw(say state given)	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?).
73		172
74	We found it annoying that we always have to enable extra features. If
75	something breaks because it didn't anticipate future changes, so be
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
80	Few modules that are not actively maintained work with newer versions of
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.
83
84	If your code isn't alive, it's dead, jim - be an active maintainer.
85		173
86	=item mucho reduced memory usage	174	=item mucho reduced memory usage
87		175
88	Just using all those pragmas mentioned in the SYNOPSIS together wastes	176	Just using all those pragmas mentioned in the SYNOPSIS together wastes
89	<blink>I<< B<776> kilobytes >></blink> of precious memory in my perl, for	177	<blink>I<< B<776> kilobytes >></blink> of precious memory in my perl, for
…		…
100		188
101	=cut	189	=cut
102		190
103	package common::sense;	191	package common::sense;
104		192
105	our $VERSION = '1.0';	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
106		205
107	sub import {	206	sub import {
108	# no warnings	207	# verified with perl 5.8.0, 5.10.0
109	${^WARNING_BITS} ^= ${^WARNING_BITS};	208	${^WARNING_BITS} ^= ${^WARNING_BITS} ^ "\xfc\x3f\xf3\x00\x0f\xf3\xcf\xc0\xf3\xfc\x33\x03";
110		209
111	# use strict vars subs	210	# use strict vars subs
112	$^H \|= 0x00000600;	211	$^H \|= 0x00000600;
113		212
114	# use feature	213	# use feature
…		…
130	=head1 STABILITY AND FUTURE VERSIONS	229	=head1 STABILITY AND FUTURE VERSIONS
131		230
132	Future versions might change just about everything in this module. We	231	Future versions might change just about everything in this module. We
133	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
134	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
135	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.
136		236
137	Most likely, we will pick a few useful warnings, instead of just disabling
138	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
139	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
140	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
141	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
142	our common sense to be consistent with, uhm, our opinion).	241	sense to be consistent with, uhm, our opinion).
143		242
144	=head1 WHAT OTHER PEOPLE HAD TO SAY ABOUT THIS MODULE	243	=head1 WHAT OTHER PEOPLE HAD TO SAY ABOUT THIS MODULE
145		244
146	apeiron	245	apeiron
147		246
…		…
149	"I hope common::sense is a joke."	248	"I hope common::sense is a joke."
150		249
151	crab	250	crab
152		251
153	"i wonder how it would be if joerg schilling wrote perl modules."	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."
154		259
155	H.Merijn Brand	260	H.Merijn Brand
156		261
157	"Just one more reason to drop JSON::XS from my distribution list"	262	"Just one more reason to drop JSON::XS from my distribution list"
158		263
…		…
191		296
192	acme	297	acme
193		298
194	"THERE IS NO 'no common::sense'!!!! !!!! !!"	299	"THERE IS NO 'no common::sense'!!!! !!!! !!"
195		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
		398
196	=head1 AUTHOR	399	=head1 AUTHOR
197		400
198	Marc Lehmann <schmorp@schmorp.de>	401	Marc Lehmann <schmorp@schmorp.de>
199	http://home.schmorp.de/	402	http://home.schmorp.de/
200		403

Diff Legend

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

Comparing common-sense/sense.pm (file contents): Revision 1.11 by root, Sat Aug 22 20:21:29 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.11 by root, Sat Aug 22 20:21:29 2009 UTC vs.
Revision 1.22 by root, Wed Nov 4 11:04:25 2009 UTC