> + my $foo = 123;
> + $r->pnotes('foo' => $foo);
> + $foo = 456;
> + $r->pnotes('foo') # <== now 456 (in 2.0.2)
> + $r->pnotes('foo') # <== left at 123 (in 2.0.3)
actually, I'm re-thinking my stance on this. a common use of pnotes is to
pass objects around. if I understand things correctly, the current
situation is this
-- some handler
my $o = Foo->new;
$r->pnotes(foo => $o);
-- next handler
my $o = $r->pnotes('foo');
$o->set(bar => 1); # sets $o->{_bar} = 1
-- another handler
my $o = $r->pnotes('foo');
my $bar = $o->bar; # 1
I actually thing that would be somewhat common. and as I understand things,
the fix would require the middle step to be
-- next handler
my $o = $r->pnotes('foo');
$o->set(bar => 1); # sets $o->{_bar} = 1
$r->pnotes(foo => $o);
in order for $o to maintain it's internal state. is that right? if so, I
don't like that very much. in fact, I'll bet that doug originally coded
pnotes to behave the way it currently does on purpose, since the original
force behind pnotes was to be able to pass objects around.
so, I think I'm leaning more towards "the current behavior is not only not
broken, it's intentional" camp.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
