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

> 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

Reply via email to