Think about Loose Coupling | |
PerlMonks |
Re^3: Perl version usageby kcott (Archbishop) |
on Dec 28, 2017 at 02:40 UTC ( [id://1206303]=note: print w/replies, xml ) | Need Help?? |
Thanks for the clarification. Unfortunately, I don't think there's a straightforward "Yes" or "No" answer to this. In a work situation, you'll often be required to code to a certain version, which could be a very old version. There can be many reasons for this, some are appallingly bad reasons; however, if you've agreed to take on a contract working with legacy code, then you're going to have to develop in an old version. In another work scenario, you may be required to upgrade old code to a more recent version. Now it becomes important to understand both the features of old and new versions. Even when working with older versions, you should aim to write your code such that it's easily converted to newer versions or, better still, requires no conversion. Just because the old version didn't pick up this classic syntax error:
does not mean you should include such an unreported error in new code written for an old version. See "perl5180delta: qw(...) can no longer be used as parentheses" if you're unfamiliar with that particular problem; be aware, that's just an isolated example of code that didn't follow the published syntax, but got away with it in earlier versions. As already indicated in my original response, I'll tend to avoid newer features in code I supply on this site. I'll generally aim to explain a technique using code that should work with whatever version of Perl the OP is using. If you're in a situation where you're mentoring, I'd recommend a similar approach; for example, use the well-known "@$aref" to initially explain a point, then introduce "$aref->@*" as a newer feature. For my personal code, I use a lot of the newest features; although, for anything that's not simply a "let's test this new syntax" script, I avoid experimental features. They will come back to bite you in the bum when their implementation is changed or, when deemed a failed experiment, removed completely. Don't use experimental features in production code. Anyway, there's a series of scenarios where "Yes", "No", "Maybe" or "Depends" could all be valid answers. You'll need to make separate judgement calls for each; based on context, requirements, in-house standards and so on. — Ken
In Section
Seekers of Perl Wisdom
|
|