Re: Enabling/using Perl 5.10+

["R. Ransbottom" <..hidden..>]

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.

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

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

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

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

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

So v.5.10.0 is fine. 

Rob

------------------------------------------------------------------------------
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
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel