Re: Enabling/using Perl 5.10+ functions: say(), state(), given/switch and "'use strict' by default"

Hi Rob,

> In the comments to his PR (
> https://github.com/ledgersmb/LedgerSMB/pull/2695#issuecomment-300053021),
> Rob suggests we should start using

> use v5.14;

Personally, I am not set on any particular version number. And that
would be most important as it would effect upgraders.

> ... that statement [use v5.14;] also means that we will automatically
> enable:

> * use strict;
> * availability of the functions say() and state()
> * availability of the switch/given construct.

I think those are all minor issues looking at Lsmb as an application or as
independent modules. These are parsing matters that can be turned on or off
with 'no feature', etc.

While true that these features can be disabled, it sounds a bit weird to enable them by using 'use VERSION;' and then to disable them again by using 'no feature;'.

> So, the question: do we want to use the 'use VERSION;' statement to set the
> minimal Perl version, with the indicated side-effects?

The big advantages are two.

1) That 'use v5.14;' does more than require a minimal Perl version. It
makes a Perl version 5.16 to 5.24 downgrade itself to version 5.14
preventing accidental collisions with newer features.

If new features don't get enabled in newer versions *unless* we use 'use VERSION;', then if we don't use 'use VERSION;' we're not likely to run into this clash...

2) Put in login.pl and setup.pl 'use VERSION;' will let us crash early
before much effort is wasted by users.

There are multiple places where we can put these:

1. The point where we declare our dependencies: cpanfile

after all, a specific Perl version *is* a dependency

2. The first lines/module which is executed when the webapp is loaded

after all, this is the first (best?) place to let the admin know executing the code won't work

3. The first lines which are executed when a page is requested in the webapp

this the point you suggest: login.pl and setup.pl

after all, this is a good time to let an unsuspecting user know that the admin failed to install the correct Perl version

Testing needs should shrink.

I don't see why you would say that. My thinking is: if a newer version is going to impersonate an older version, then there's probably new "impersonation code". New code can have bugs and so we should probably still run our tests on all versions from lowest to newest.

What the Perl version requirement means to my, by the way, may not be the same as it means to you: to me, it means "yes, we tested the software on this Perl version and we think it should work; if it does not, we're motivated to *make* it work".

Note that the above definition does *not* mean, "we'll actively try to prevent this application from working on any version prior to X". I'd like our minimum version requirement to mean "run at your own risk; try if you might and if it fails, you're on your own".

A rigorous and enforced definition of
coordinated user/developer platform requirements is just tighter practice.

I'm not sure what you mean by this in the context of Open Source Software. I mean, we can hardly enforce what combination of dependencies and software versions people will use: many distributions will have their own "standard"/"shipped" versions. Not supporting those versions (as in: actively preventing the combination from running) means that packagers can't package for those distros. Supporting those versions (as in: we'll try to fix it if it doesn't work) helps packagers help us bring our software to as many platforms as possible.

>From the developer's perspective, I don't think there is much pain
involved. I have gone from 5.004 to 5.24 and scarcely noticed anything
but improvements.

Ok. It's good if there's not much pain involved for developers :-) However, is there also little pain involved for packagers and for end-users? If the answer there is "yes" then there's no problem to move to this scheme. However, if the answer is "no, there will be pain involved" then a bit of pain for the few (the developers) helps aleviate the pain of the masses (the users).

Note however that I would not call the number of tests we run on all the supported Perl versions "a pain" -- so little even that I've never considered anybody might feel that way about it.

On the other hand:

I have not used this feature much. So, to this point, I am trusting
the P5Pers are doing it right. I have volunteered to investigate the
robustness of this feature before any action is taken.

Tighter controls can be a bother--although I don't think this one would
be much of one in the day to day development.

That a higher 'require XXXXX;' is in some Perl dependency causes a late
death. This could be avoided by auditing dependencies at setup. This
is a bit of work but also has merit in itself.

Writing at v5.6 is comfortable.

While writing at that version might be comfortable, I've found that I highly appreciate the '//' operator which is available since 5.10 (for those unaware, it's the short hand of "(defined X) ? X : <some value>" if you write "X // <some vaule>".

Currently, this is the main reason to declare that our code depends on 5.10. Because the number of released versions between <newest> and 5.10 is an ever-growing list, we decided to stop testing 5.10 and 5.12 -- effectively making 5.14 the lowest supported version. The code *might* run on 5.12 and 5.10 however. (Though it certainly won't on 5.8.)

Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.

Robust and Flexible. No vendor lock-in.