On Fri, Dec 23, 2005 at 10:43:23AM +0100, TSa wrote:
> HaloO,
>
> Nicholas Clark wrote:
> >Well, I assume that the do-nothing sub is assigned into the variable, and
> >gets re-evaluated each time the variable is use. Which would mean that
> >you'd
> >get a new (different) empty hash each time. Whereas an empty hash
> >constructor
> >gives you a hash reference to keep. (not just for Christmas)
>
> Hmm, I think the type of value stored in $foo after
>
> my $foo = {};
>
> is Code ^ Hash which is viable for &postfix:{'<','>'} which when
> assigned to drops the Code from the type. And I further think that
> a plain {} empty code literal doesn't have the is rw property set
> and thus something like
>
> $foo()<blahh> = 23;
>
> is not allowed. The above shall mean that the code in $foo is evaluated,
> delivers a fresh, empty hash which gets the kv blahh => 23 and then is
> lost.
Oooh. Interesting if that all can work.
> >It's like the autovivification bug:
> >
> >sub stuff {
> > my $h = shift;
> > $h->{k}++;
> >}
>
> Do you consider that a Perl5 bug or a program bug? I find it
I should have been clear - program bug, given that the behaviour of the Perl
language is well documented. Just one that I've been got by a few times.
Things that "usually work" until you happen to have data that never caused a
variable to become autovivified to a reference before the "reference" gets
copied.
> inconsistent with respect to $h beeing either a const alias
> to $a and thus always a detached copy after the shift or it
> should always install the autovivified hash also into $a. But
> the mixed mode of directly accessing the hashref in $a if it
> refers to a hash already is at best surprising. The Perl6
> sub declarations make this much clearer:
>
> sub stuff (%h is rw)
> {
> %h<k>++;
> }
Good point. I'd not thought how that would help clear this up.
Nicholas Clark
