Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw

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

by CountZero (Bishop)
on Jan 11, 2013 at 10:25 UTC ( #1012855=note: print w/replies, xml ) Need Help??

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};
and then make sure you change your tests to include the exists function.


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

Replies are listed 'Best First'.
Re^4: Undesirable parent hash keys (concept?)
by tobyink (Abbot) 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;
    perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1012855]
[robby_dobby]: Corion: Heh. This whole thing smells of Strategy Pattern or MVC pattern.
[Corion]: And performance linear to the number of registered one-shots doesn't feel that bad. Maybe I should collect statistics on how many callbacks are outstanding ;)
[Corion]: choroba: Yes, but the longer I thought about efficient hashes mapping the event type back to their callbacks, and how to keep them in sync, the more I thought that all that optimization might just not be worth it, even if it's horribly inelegant
[Lady_Aleena]: My biggest problem with hashes at the moment is one with 2,501 keys.
[choroba]: how many event types are there?
[Corion]: Also I found that I can't conveniently weaken an array slot, which also is inconvenient, as I want my one-shots to disappear if the caller discards them
[Corion]: choroba: Currently two or three that my program handles (WWW::Mechanize:: Chrome), but there might be more that become interesting
[Corion]: But I don't expect more than 100 to be active at the same time, so I'm not really sure if there is a not-too-fancy data structure that is maintained with few lines of code where the performance is better than the linear scan ;)
[Corion]: But I should do a mock-up program so that others can see what I'm talking about ;)
[robby_dobby]: Corion: I hope you know all too well that passing around "fancy" datastructures is a recipe for disaster :-)

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (7)
As of 2017-05-29 07:56 GMT
Find Nodes?
    Voting Booth?