Mailing-List: contact modperl-help@perl.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of aw@ice-sa.com designates
 212.85.38.228 as permitted sender)
Message-ID: <4BD54D3A.7070804@ice-sa.com>
Date: Mon, 26 Apr 2010 10:22:18 +0200
From: =?ISO-8859-1?Q?Andr=E9_Warnier?= <aw@ice-sa.com>
Reply-To: mod_perl list <modperl@perl.apache.org>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: mod_perl list <modperl@perl.apache.org>
Subject: Re: Getting a / when regex should produce nothing
References: <4BD3AB3D.1040900@bennettconstruction.biz>
 <4BD41D28.8020502@ice-sa.com> <20100425181754.GA912@wladimir>
In-Reply-To: <20100425181754.GA912@wladimir>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Michael Ludwig wrote:
> Andr� Warnier schrieb am 25.04.2010 um 12:44:56 (+0200):
> 
...
>>> no warnings 'uninitialized';
>> is very dubious.
> 
> I used to think so, too, but I've recently changed my mind.
> 
...
Michael, I have no doubt that your intrinsic perl knowledge surpasses 
mine, but I disagree, not with the details of what you mention, but on 
the general spirit and in the context.  And I find your quoting of the 
common::sense module a bit biased, again not in the details but in the 
spirit in which you seem to "recommend" it, again in this context.  I 
like the module, but in the sense that it seems indeed a useful shortcut 
for a number of *explicit* assertions which *some* perl coders use. 
Which is what its description honestly says :
"This module implements some sane defaults for Perl programs, as defined 
by two typical (or not so typical - use your common sense) specimens of 
Perl coders. In fact, after working out details on which warnings and 
strict modes to enable and make fatal, we found that we (and our code 
written so far, and others) fully agree on every option, even though we 
never used warnings before, so it seems this module indeed reflects a 
"common" sense among some long-time Perl coders."

However, many years of designing and programming stable and reliable 
applications in perl have taught me to prefer explicit code, 
understandable and maintainable also by other people; this as compared 
for example to relying on assumptions about the compiler's defaults.
And for this OP, who on the face of it is not a perl guru, all the more so.

In my view, code such as
$article_file = $q->param("articlefilename");
(and then proceeding to use $article_file without further ado)
in a web application, is ok if you know exactly what you are doing, and
if you know somehow that the client cannot "not send" this parameter in
the request, and that it cannot send it empty, and that even if it does, 
it does not matter all that much anyway; and that the person who
is going to re-read your code in 6 months knows as much about perl's
internals as you do.

$article_file = $q->param("articlefilename") || '';
does not add much technically, since as you rightly mention perl already
does that, in a way (although not at the same time or place).  But it 
makes *explicit* what you are doing, which makes the difference to 
someone maybe not as fluent in perl and who has
to look at that code in a year's time.

In a real web application with which people interact through a browser
and a html form, I would have made it even much more defensive and 
explicit, like :
$article_file = $q->param("articlefilename");
unless ((defined($article_file) && ($article_file ne '')) {
   return an error of type "essential info not submitted"
}
unless ($article_file is-what-we-expect) {
   return an error of type "invalid value submitted"
}
because in this case, that filename seems to be the real essential
element of the application, so I would not want an empty or undefined
value to even create a doubt as to where it comes from or what happens
with it.  And I know that this is not elegant code; but it is code that 
will survive another version of perl, another version of 
Apache::Request, and another version of the programmer maintaining it.

I will qualify all the above by adding that this regards application
code, written and/or read and/or modified by programmers whose skills vary.
It is on the other hand perfectly ok in my view for a perl guru to write 
perl modules using whatever clever techniques and idioms suit him, as 
long as the module does what it claims to do.  And as long as 
(preferably) any section of such code comes with ample internal 
documentation explaining what it does and what it relies on.