Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery

Re: The Bad, the Ugly, and the Good of autovivification

by 5mi11er (Deacon)
on Apr 08, 2005 at 15:43 UTC ( #446051=note: print w/replies, xml ) Need Help??

in reply to The Bad, the Ugly, and the Good of autovivification

There is something, added to 5.8, that could help catch the "typo"s from happening. I've been a lurker on the perl5-porters mailing list, and one of the more fascinating discussions I read about, back when I was actually able to take time to read that list, was an idea about creating "clamped" hashes. The idea was to help eliminate accidentally creating hash keys, but it grew from there.

The current implementation has been made a core module called Hash::Util, you can read about it here.

In an attempt to quickly summarize what you'll find at the link above, the following methods are available:

Method Description
lock_keys(%hash)don't allow any keys other than what currently exists
lock_keys(%hash,@keys)dont allow any keys other than those in the array @keys
unlock_keys(%hash)unlock the hash to be able to add keys
lock_value(%hash,$key)Keep the value at $hash{$key} from being changed
unlock_value(%hash,$key)Allow the value to change
lock_hash(%hash)don't allow keys or values to change
unlock_hash(%hash)allow keys and values to change


  • Comment on Re: The Bad, the Ugly, and the Good of autovivification

Replies are listed 'Best First'.
Re^2: The Bad, the Ugly, and the Good of autovivification
by Anonymous Monk on Apr 08, 2005 at 16:18 UTC
    Yeah, unfortunally, for algorithms that use 'exists', clamping hashes doesn't make sense. Either the key is known to be there (so, no need for exist), or its existance is volotile, which means that clamping hash prevent the keys from being inserted.

    Sure, you can unclamp the hash whenever you insert a new key, but then it might be easier to write your exist test as:

    $exists = exists $hash{key1} && exists $hash{key1}{key2};
      I don't think the first part of your argument is strictly true. If you use the @key's option, it would be possible for keys to not exist, or to be added dynamically, thus you might still need to see if that key happened to exist or not.

      However, you're correct that none of this stuff helps at all with respect to "auto-vivication". And your code example does appear to help work around the problem when dealing with nested structures.

      Hmm, Merlyn recently posted a snippet that walked a structure to it's leaf nodes, maybe we could combine the ideas of that snippet with this code to create a new form of exists?


      PS. the last paragraph was written "tongue-in-cheek", but it's late, and I would not be at all surprised to come into work on Monday to find someone actually wrote such a beast...

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://446051]
[Corion]: erix: Sure, but this is for a really-lightweight application and I'm replacing a CSV file / JSON file for user configuration with SQLite (and optionally, Pg) :)
[erix]: isn't a texty format handier for configs?
[Corion]: So far, I've avoided having even a user database by storing the user information in a (signed) cookie that the browser keeps for me, but as I want to be able to lock users, I need a second storage option :)
[Corion]: erix: It's needed for keeping the list of users and the list of tags associated with an image, and for keeping the images with users. I want an easy way to know if an image can be deleted, which means that it can't be referenced by any tag anymore. ...
[Corion]: SQL feels like a natural choice here :)

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (15)
As of 2018-03-20 14:08 GMT
Find Nodes?
    Voting Booth?
    When I think of a mole I think of:

    Results (253 votes). Check out past polls.