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