Front page | perl.perl5.porters |
Postings from September 2011
Another possible approach re version compatibility
Thread Next
From:
Green, Paul
Date:
September 29, 2011 15:13
Subject:
Another possible approach re version compatibility
Message ID:
5AA430FFE4486C448003201AC83BC85E021E7416@EXHQ.corp.stratus.com
I've been following the debate regarding the challenges of defining and
implementing a Perl statement that would declare the compatibility
requirements of a Perl source program. I think this is a wonderful
idea, and one that is long overdue, but is also one that has some
difficult challenges to resolve. As an implementer, I'm very concerned
about the burden it will place on the Perl implementation community.
Basically, as much as I love the idea, I think it will be difficult, if
not impossible, to implement. The Perl interpreter is already a pretty
complicated body of source code, and I don't see this plan making it any
simpler.
Here's another way to approach this issue, which I would define as "Give
the author of Perl source code a method to ensure that his or her Perl
source code works as intended or fails fast with a clear error message."
I think this is pretty close to the original definition by Jesse, but
recasts it as a burden on the author instead of on p5p.
What if we gave Perl programmers a way to say "I have tested this module
against Perl Version X.Y and it works as I intended".
In other words, if I am responsible for a body of code, and if it passes
all of my tests on a particular version of Perl, then I would insert a
statement to that effect in the program. If at some point down the
line, someone attempts to run my program on a newer (or older!) release
of Perl, it will print some sort of clear diagnostic.
The advantage of such a statement is that I suspect many people don't
use the full generality of Perl, and can live with many of the
underlying changes that happen from release to release. This gives them
a way to say "It's OK to use v5.18, or v5.20, or v5.22 but nothing
else". Even if v5.22 is known to break some Perl programs, I can tell
the world that it hasn't broken my program.
I leave it to others to define a syntax for such a statement. We would
want a way to allow a range of versions, and perhaps a way to specify
the consequences of a mismatch.
I can see a number of practical drawbacks, especially for someone
responsible for a large body of code, as in CPAN. Any toolsmiths out
there? But I think it would be a lot easier to implement, and I think
it enables the Perl community to make strong statements about
multi-version compatibility, without forcing the Perl5 development
community to carry along (design / code / test / bug fix) multiple
implementations.
Of course, this idea is not mutually exclusive with the "use version
X.Y" proposal. One could do both. (Yikes. Just a thought.)
We call this process "software qualification" here at Stratus. We test a
layered product against one or more releases of the underlying operating
system, and then we restrict customers to using only the combinations we
have qualified. Well, we restrict customers who purchase a support
contract from us. We don't care what other changes happened to the OS,
as long as the layered product still works. We certainly don't try to
teach the new OS to behave like the old OS when a particular layered
product is running. The overall process works well. We are small enough
we can do it all on paper, but I think for Perl it should be written
into the source program.
Thoughts?
Thanks
PG
--
Sr. Technical Consultant, Stratus Technologies Inc.
Work: +1-978-461-7557; FAX: +1-978-461-3610; Twitter: stratuspaulg
Thread Next
-
Another possible approach re version compatibility
by Green, Paul