[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Enabling/using Perl 5.10+

On Sun, May 14, 2017 at 3:23 AM, R. Ransbottom <..hidden..> wrote:
On Fri, May 12, 2017 at 10:13:53PM +0200, Erik Huelsmann wrote:
> Hi Rob,

> > Personally, I am not set on any particular version number.  And that
> > > ... that statement [use v5.14;]  also means that we will automatically
> > > * 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
> 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;'.

I meant:  First,these features are not fearsome to use.  Second, that
if 'use v5.14' caused code to break because someone defined a 'state()' that
conflicts with the builtin, disabling the feature is an expeditious fix.

IIRC, given/when is deprecated again :-P

I am of the opinion we add the use VERSION when we need it but don't make it a part of the boilerplate because it is a maintenance point. 

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

> > 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...

This is not correct.  There are many changes which don't need to be
turned on.   Are we _likely_ to run into them?  I would guess not likely.
But character and UTF'ish stuff keeps evolving, builtins get added.
Minor aspects of chdir's behavior have changed.  I am not an expert on
perl version differences, but the point of 'use VERSION' is to run code
in a better defined language.

Yeah, my experience is  a lot of features don't need to be turned on which can lead to accidental problems if you have a version that is too old.  The // operator is one that has bitten me in the past.

My understanding is that what the use version statement does is enable a set of features associated with a given Perl version or higher.  But some parse-level constructs are not affected.

So my view here is that we document minimal supported Perl versions.  We don't enforce this with a use VERSION statement.  We use VERSION as needed for our code and that is it.

> 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

I am using perl v5.20.2 (64bit) not the v5.10 designated as a dependency.
Did not even think about it.  This is an argument

> 2. The first lines/module which is executed when the webapp is loaded
> 3. The first lines which are executed when a page is requested in the webapp

Both seem reasonable and sufficient.

> > 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.

That is true, but the 'impersonation code' is being stressed by many not
just us.

> 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".

I am interpreting that as:
run at your own risk ON EARLIER VERSIONS ... if it fails, you're on your own.

Okay, but given the mission of the code, I think it is reasonable to
warn users by dying and requiring them to override the requirement.  What if
it is months before they start to implement the work flow that breaks on
a divergent system?

Adding it to the cpanfile should be sufficient for that, I think. 

> [ A lot supporting an intention to allow a broad population of
>   of users a chance to access to the beauty of Lsmb even if
>   they are not meeting the prerequisites for support.
> ]

I am not trying to change the marketing philosophy of Lsmb.

Better code fails sooner and more obviously than poorer code.

I tend toward loyalty so I appreciate the intention to support old versions
and old platforms.  That does take energy away from current and future

I ran into someone a month ago who was maintaining Perl 3.x code......  Obviously not LSMB :-D

> 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.

> > Writing at v5.6 is comfortable.

> I highly appreciate the '//' operator which is available since 5.10 (for

And //=, given, when, say, and state are lovable, too.  I like not using
closures to have static variables.

Yeah, then we add the use version where we need it.  But i understand given/when to be deprecated for good reasons.

> Currently, this   [use of //]
> 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.)

So testing is a pain that has been ameliorated.

I have little opinion on where the line, "$^] > '5.0NN' or die;" or
'use v5.NN.N;' should be drawn.  Just that it is good to draw it
So v.5.10.0 is fine.


Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Ledger-smb-devel mailing list

Best Wishes,
Chris Travers

Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor lock-in.
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Ledger-smb-devel mailing list