perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Foertsch <>
Subject Re: [MP2] possible pnotes bug?
Date Thu, 08 Jun 2006 07:21:35 GMT
On Wednesday 07 June 2006 22:07, Perrin Harkins wrote:
> Me too.  I don't think this is a bug, since it behaves normally for a
> Perl hash.  It's been documented now, and I think that should be the end
> of it.

No, it does not. $r->pnotes->{key}=value behaves like a Perl hash.
$r->pnotes(key, value) does not. But anyway if you all think it's okay the way 
it is I'll simply not use the second version anymore.

Look at the implications of this bug. One starts a module with this code in 

$r->pnotes( lang=>'de' );

This will work and is okay. Later someone invents a language hash:

$r->pnotes( lang=>$lang{CGI::param('language')} );

Even this still works because %lang is in fact read-only. But then in the next 
release the code is changed to:

my $lang=$lang{CGI::param('language')};
$r->pnotes( lang=>$lang );
if( $lang eq 'de' ) {
} elsif( $lang eq 'us' ) {

Now the code is faulty. After $lang='de_DE' also the pnote is 'de_DE' not just 
'de' as expected.

And please note, this can happen years after the initial innocent looking 
$r->pnotes(lang=>'de') had been written. Had it been $r->pnotes->{lang}='de' 
in the first place the code would still be okay.


View raw message