[vetler]

Maybe they should use classes and objects instead of hashes. I.e.

    $session->ab_variation_overrides();

This would prevent them from mistyping ab_variation_overrides everywhere they need it... But of course, it's a lot easier to solve everything with hashes in Perl. Been there, done that!

[draegtun]

Another solution could be to lock the keys of $config after its been configured:

  use Hash::Util 'lock_keys';

  our $config;
  $config->{file_paht} = "/opt/app/data_file";
  lock_keys( %$config );

Now any attempt to use an undefined key will throw an error. So on the open() it would now throw error: Attempt to access disallowed key 'file_path' in a restricted hash at...

[douglashunter]

This is what Kris Arnold (https://twitter.com/wka), one of the other hackers here at Shutterstock recommended. I like it.

[draegtun]

Me to, especially as it covers both problems you've given in the post.

Now I just need to get into the habit of using Hash::Util::lock_keys more often myself :)

[jerf]

While that can be helpful, that comes with its own set of problems. It's harder to say $session->ab_variation_overrides ||= {inital => "values"}. I think it's possible, but I've been warned off by the huge EXPERIMENTAL warning around the lvalue subroutine return documentation [1] and the fact that it's been labelled "experimental" for a long time now, so I don't dare put it in production code, or use it where I can't count on someone knowing everything in those docs. I've been in tight loops where the cost of a function call was noticeable vs. the hash lookup. You can't avoid the fact that lots of other libraries and existing code expects hashes in one form or another (the calling convention that essentially puts a hash in a list is just another variant of that).

You're not "wrong", but it doesn't solve very much of the problem in practice. Still, it can be useful where appropriate, and there are libraries that use such approaches for safety; here's one example off the top of my head [2].

This is where I really prefer Python over Perl; Perl nominally has bullet-point feature compatibility with Python in most respects, but where in Perl operator overloading, tying, and the various other ways of overloading things always come with caveat lists a mile long and often go together poorly, in Python they Just Work, and actually can be used together. In this case, properties. They work. I've even made them dance and sing before with nonstandard behaviors and they still work.

[1]: http://perldoc.perl.org/perlsub.html#Lvalue-subroutines

[2]: http://search.cpan.org/~mlehmann/JSON-XS-2.32/XS.pm

[douglashunter]

Well, that's embarrassing. I fat-fingered those while I was transcribing code into the article. "Surprise Two" was supposed to be about the autovivification surprise, not me mistyping things (article updated).

Even still, your point about using objects and encapsulation stands. If the session were being assigned to via setters, and read from with getters, the grep aliasing wouldn't do its damage.

Cheers.