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 Fri, 09 Jun 2006 18:19:38 GMT
On Friday 09 June 2006 19:21, Geoffrey Young wrote:
> > This is said in the description of pnotes:
> >
> >    $hash_ref = $r->pnotes();
> >    ...
> >    if no arguments are passed, a hash reference is returned, which can
> > then be directly accessed without going through the "pnotes()" interface.
> >
> > Since a hash reference is returned it is clear that it is accessed as
> > pnotes->{key}.
> I'm not doubting the interface exists.  I'm saying that it's not in use
> in the wild nearly as often as the method call.

Yes, I was using it too until it has bitten me, ;-)

> > I think the behavior of $r->pnotes(key=>value) is buggy not because I
> > want something special. I want it to behave simply like an ordinary perl
> > hash.
> >
> > Further I really think it is buggy because it leads to very difficult
> > traceable bugs in applications using it. The docs says:
> >
> >          $r->pnotes(foo => [1..5]);
> >          $val = $r->pnotes("foo");
> >
> > If this example is changed into:
> >
> >          $var=[1..5];
> >          $r->pnotes(foo => $var);
> >
> >          $var=[’a’..’c’];    # this changes the pnote behind the
> >
> >          $val = $r->pnotes("foo");
> >
> > What would you expect $val to be? [1..5] or [’a’..’c’]?
> >
> > I think every new programmer and even almost all experienced mod_perl
> > users would say it is [1..5].
> but this has nothing to do with it, really - we're talking about
> changing the way $r->pnotes(key => value) has historically behaved for,
> what, 8 years?  you can't just do this on users and introduce wickedly
> difficult bugs to track down without some serious consideration.  well,
> you can do whatever you want with your own code, but mod_perl as a
> project has an obligation to its established userbase to not introduce
> pain on purpose, or at least without due warning (such as would come
> from a major version bump).

I understand.

You can look at it in two ways.

1) no matter what, it has been this way for 8 years. So don't touch it!
But since the behavior is really weird it must be described and thoroughly 
explained (as I have tried to do this morning).

2) it is a long surviving bug.
Again, because the behavior is weird I think there is a certain amount of 
applications out there using this feature that work only by accident. There 
is certainly a certain amount of applications using this feature 
deliberately. But if a program relies on variables changing by itself behind 
the scene it is in my opinion not maintainable and belongs rather to the 
obfuscated perl contest.
I think, people that got bitten by this bug simply did not complain and 
changed their code more or less randomly unless it had worked somehow. Simply 
introducing a new variable $var2=[’a’..’c’] would have cured the problem.

But I understand that such a change cannot be done without due warning. We all 
remember well the complains after 2.0.0-rc5 or so was released.

We could document the current behavior of $r->pnotes(key=>value) and mark it 
as to be changed in a future release. How about that?


View raw message