Versions 5.11 and above automatically activate strict mode. Specifying the exact version number plus a line activating warnings isn’t too much boilerplate, I think.
TBH I just started using Modern::Perl after getting the book. I’ve added the boilerplate as an abbrev in Emacs so I don’t have to bother with remembering it.
Hahah, yeah, fair enough. I usually do all that (hm, well, not always env – there are some tradeoffs) but I figured if I was going to go old-school may as well go all the way. Inscrutable runtime errors are the spice of life, right?
I think spetz was saying I /should/ have done those things but didn’t. If you learned to do things that way, I think you’re still good-to-go. Though some folks up-thread mentioned some other options that may have additional benefits if you’re running a recent-enough version of Perl.
Exactly, my fingers automatic type strict and warnings when starting a new perl file.
I read up on the other examples and I like them.
Personally I don’t care for ‘say’ and use print/printf but there is other benefits. In my world mostly that the script will behave on a server the same way it does when developing it, and that’s a point I will take with me.
I find it very amusing that this projects basically start with code that looks a lot like cgi-lib.pl, which gives me flashbacks to my first Perl/CGI scripts from the mid-90ies
That’s great! That’s exactly the time I was thinking of when I wrote it. Glad it came through. Fun times, but I’m happy we don’t still have to write everything that way.
One question. In many frameworks, multiples of the same param key are treated as an array of values. Did you get your approach, taking the last value as canonical, from a standard out there? I always wondered if there is something that tells us how to handle that.
Thank you for the kind words! I’m not familiar with a specification for the content of a query string. I see that RFC 3986 mentions “query components are often used to carry identifying information in the form of key=value pairs.”
I’ve seen it handled three ways: first-value, array, or last-value. First-value may have some security benefit in particular contexts for resisting additional parameters being added to the end. Array, of course, is handy if you want to accept an array. Last-value is easy to implement. I’ve also seen conventions like “array[]=foo;array[]=bar;array[]=baz” or “foo[bar]=baz” used to encode more complex data structures.
Pet peeves:
#!/usr/bin/env perl
use strict;
use warnings;
or
I personally find it clearer to do
Versions 5.11 and above automatically activate strict mode. Specifying the exact version number plus a line activating warnings isn’t too much boilerplate, I think.
I like the Modern::Perl invocation because you get
saytoo.But it is an extra dependency for sure.
use v5.10and later should also enablesay.TIL, thanks.
TBH I just started using Modern::Perl after getting the book. I’ve added the boilerplate as an abbrev in Emacs so I don’t have to bother with remembering it.
also of note —
Also learned that 5.12 is Y2038 compliant
That’s good to know! My plan to live forever is working so far…
Hahah, yeah, fair enough. I usually do all that (hm, well, not always env – there are some tradeoffs) but I figured if I was going to go old-school may as well go all the way. Inscrutable runtime errors are the spice of life, right?
For those of us who haven’t used perl in a long time (and IIRC were taught this way), what should we be doing instead and why?
I think spetz was saying I /should/ have done those things but didn’t. If you learned to do things that way, I think you’re still good-to-go. Though some folks up-thread mentioned some other options that may have additional benefits if you’re running a recent-enough version of Perl.
Exactly, my fingers automatic type strict and warnings when starting a new perl file. I read up on the other examples and I like them.
Personally I don’t care for ‘say’ and use print/printf but there is other benefits. In my world mostly that the script will behave on a server the same way it does when developing it, and that’s a point I will take with me.
Oh you’re no doubt correct, my bad, ty.
I find it very amusing that this projects basically start with code that looks a lot like cgi-lib.pl, which gives me flashbacks to my first Perl/CGI scripts from the mid-90ies
That’s great! That’s exactly the time I was thinking of when I wrote it. Glad it came through. Fun times, but I’m happy we don’t still have to write everything that way.
I love this! Great project concept!
One question. In many frameworks, multiples of the same param key are treated as an array of values. Did you get your approach, taking the last value as canonical, from a standard out there? I always wondered if there is something that tells us how to handle that.
Thank you for the kind words! I’m not familiar with a specification for the content of a query string. I see that RFC 3986 mentions “query components are often used to carry identifying information in the form of key=value pairs.”
I’ve seen it handled three ways: first-value, array, or last-value. First-value may have some security benefit in particular contexts for resisting additional parameters being added to the end. Array, of course, is handy if you want to accept an array. Last-value is easy to implement. I’ve also seen conventions like “array[]=foo;array[]=bar;array[]=baz” or “foo[bar]=baz” used to encode more complex data structures.