perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Young <>
Subject Re: [MP2] possible pnotes bug?
Date Fri, 09 Jun 2006 17:21:18 GMT

> 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.

> Btw, this description does not mention a tied hash. Maybe because it is in 
> fact not tied. It is a normal perl hash only hidden in the C layer.

yeah, ok, I was wrong.  all the APR::Table foo is tied, but pnotes is
not.  blasted inconsistent interfaces...

> 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 scene
>          $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).


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message