develooper Front page | perl.perl5.porters | Postings from September 2011

Re: The future of POSIX in core

Thread Previous | Thread Next
Nicholas Clark
September 2, 2011 08:05
Re: The future of POSIX in core
Message ID:
On Fri, Sep 02, 2011 at 10:27:18AM -0400, David Golden wrote:
> On Fri, Sep 2, 2011 at 10:04 AM, Mark Overmeer <> wrote:
> > Counting back from Feb/2012 there must be a moment not too far away
> > when the user-visible changes get frozen. So, about when?
> >
> > The whole purpose of this thread was to check with "Core" what would
> > be the best way to get the changes into 5.16. Where goes what. Still
> > not completely sure where the consensus will get us.
> For Perl 5.14, the "contentious change" freeze was late December 2010.
>  The "user-visible change" freeze was late Feb 2011.  The "hard"
> freeze to start the RC cycle was late March 2011.

And the sequence of patches as a whole proposed user-visible changes.

> I haven't seen anybody object to a documentation patch for
> I would suggest submitting that as a distinct patch.  I will commit to
> personally reviewing it and providing feedback (or else I will just
> commit it if I think it's close enough).
> I have no objection to splitting out POSIX::SigAction and POSIX::SigRT
> into separate .pm files that are used by  (I.e. loading
> POSIX should load those also.) I would accept a patch for that.

What does this gain? I don't think that it simplifies anything.

POSIX::SigAction would always be loaded by POSIX::SigRT (because the
latter uses the former) and POSIX::SigRT would always be loaded by POSIX
(because %POSIX::SIGRT is implemented by the methods in POSIX::SigRT)

It would increase the number calls to stat() and open() to load POSIX,
without (I think) reducing in any way the compile time or runtime resources

> I don't hear consensus for changing the POSIX @EXPORT API.  I think
> that is not going to get sufficient support.
> There is the outstanding proposal for applying the correct prototypes
> to POSIX clones of Perl functions.  Given the disagreement, I think we
> need Jesse to make a call.   I suggest creating a new thread on that
> topic specifically and ask him to render judgment.

I suspect that the wrapper functions in question are rarely used in any
new code. I suspect that they are used in existing code, given that there
is >15 years of Perl 5 code out there that could be using them.

Adding prototypes might help catch some bugs earlier in new code.
But without them such code would immediately fail when tested. So the bugs
they might catch would likely be found anyway soon, and not reach production

Adding prototypes might create parsing errors in working code, and hence
upgrading perl to a version with a POSIX module with prototypes could break
working production code.

My judgment is that on balance the consequences of the latter are much
worse than the benefits of the former.

Nicholas Clark

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About