On Sun, May 14, 2017 at 3:23 AM, R. Ransbottom <rir...@comcast.net> 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
> product.
>
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
> 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
> Ledger-smb-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
>
--
Best Wishes,
Chris Travers
Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor
lock-in.
http://www.efficito.com/learn_more
------------------------------------------------------------------------------
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
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
