Re^3: Undesirable parent hash keys (concept?)

in reply to Re^2: Undesirable parent hash keys (concept?)
in thread Undesirable parent hash keys

Then the only practical solution is to switch off autovivification. But take care to do it only in a limited scope because many other modules may still need it and could break unexpectedly if it is switched off.;

It is probably more safe to do a no autovivification 'exists'; as this turns off autovivification for dereferencing expressions that are parts of an exists only, such as :

exists $arrayref->[1][2][$idx]
exists $hashref->{this}{that}{$key};
[download]

and then make sure you change your tests to include the exists function.

CountZero

A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

My blog: Imperial Deltronics

Comment on Re^3: Undesirable parent hash keys (concept?) Select or Download Code

Replies are listed 'Best First'.
Re^4: Undesirable parent hash keys (concept?) by tobyink (Canon) on Jan 11, 2013 at 10:34 UTC
autovivification has lexical scope, so if other modules rely on autovivification, then using `no autovivification` in your script/module shouldn't harm them. (The only exception I could think of would be modules that play with B::Hooks::Parser, etc, to do weird stuff within your lexical scope.) I don't see much value in explicitly specifying the `'exists'` option for the autovivification pragma, as the default options are pretty sane: when `no autovivification` is in effect, autovivification will still be allowed for "store" operations... `use strict; use warnings; no autovivification; # default options use Data::Dumper; my $ref = undef; $ref->{foo}[0]{bar}[0] = 42; # store print Dumper $ref;` [download] `perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'`	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^4: Undesirable parent hash keys (concept?)
by tobyink (Canon) on Jan 11, 2013 at 10:34 UTC

autovivification has lexical scope, so if other modules rely on autovivification, then using no autovivification in your script/module shouldn't harm them. (The only exception I could think of would be modules that play with B::Hooks::Parser, etc, to do weird stuff within your lexical scope.)

I don't see much value in explicitly specifying the 'exists' option for the autovivification pragma, as the default options are pretty sane: when no autovivification is in effect, autovivification will still be allowed for "store" operations...

use strict;
use warnings;
no autovivification;  # default options

use Data::Dumper;

my $ref = undef;
$ref->{foo}[0]{bar}[0] = 42;  # store
print Dumper $ref;
[download]

perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom