Perl: When DWIM Doesn't
bits.shutterstock.com
Perl: When DWIM Doesn't
1–10 of 28 posts
Re: Perl: When DWIM Doesn't
#2Maybe they should use classes and objects instead of hashes. I.e.
$session->ab_variation_overrides();
Re: Perl: When DWIM Doesn't
#3Maybe 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!
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.
Re: Perl: When DWIM Doesn't
#4re: open() creating temporary file if file arg is undef
Fortunately both IO::File (core module) & Path::Class don't do this:
use IO::File;
my $fh = IO::File->new( $config->{file_path}, 'r' )
or die "can't open $config->{file_path}: $!";
use Path::Class qw;
my $fh = file( $config->{file_path} )->openr;
ref: https://metacpan.org/module/IO::File | https://metacpan.org/module/Path::Class
Re: Perl: When DWIM Doesn't
#5Maybe 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!
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
Re: Perl: When DWIM Doesn't
#6Maybe 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!
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 );
Re: Perl: When DWIM Doesn't
#7I love Perl. I wrote it professionally for 10 years. I have great friends who still do. The community is full of smart, fantastic people.
Five years ago, however, I learned Python for a job and never looked back. In terms of programming languages they're practically the same thing. But Python is easier to read, easier to write, and easier to hire for. And stuff like this (dereferencing, "array context," worrying about how to create my objects) makes me sigh.
Perl, I love you, but I'm not looking back.
(apologies for the language flame war bait)
Re: Perl: When DWIM Doesn't
#8[deleted]
Re: Perl: When DWIM Doesn't
#9Maybe 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!
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...
This is what Kris Arnold (https://twitter.com/wka), one of the other hackers here at Shutterstock recommended. I like it.
Re: Perl: When DWIM Doesn't
#10[deleted]
In the cases in the article, strict and warnings won't save you.