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

Re: The future of POSIX in core

Thread Previous | Thread Next
Nicholas Clark
September 4, 2011 11:13
Re: The future of POSIX in core
Message ID:
On Sat, Sep 03, 2011 at 04:11:45AM +0200, Aristotle Pagaltzis wrote:
> * David Golden <> [2011-09-02 18:20]:
> > On Fri, Sep 2, 2011 at 11:05 AM, Nicholas Clark <> wrote:
> >>> 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.
> >
> > Assuming some future where POSIX is broken up in to separate
> > sub-modules and remains just as a shell to "export
> > everything by default", then I think it makes sense to split up.
> >
> > E.g imagine:
> >
> >    use POSIX::errno;
> >
> > If we go that way, then I can load just the errno bits without all
> > the rest of POSIX functions that I don't need.  In a world split

But you can also do pretty much that if POSIX uses AutoLoader.

> > out like that, then splitting out POSIX::SigActioni/RT makes sense
> > to me. (Though maybe they just wind up as inner packages in
> > a POSIX::signal module.

But I don't think that one can, if one wants to preserve the current
POSIX semantics. POSIX export %SIGRT. The assumption of Perl programmers
has been that if &BAR is exportable from package FOO, then as part of
the public API it's just as legitimate to reference it as &FOO::BAR, instead
of importing it. Likewise %BAZ as %FOO::BAZ.

Hence as POSIX exports %SIGRT, then anything loading POSIX can legitimately
expect to access %POSIX::SIGRT with no further action. Which implies that
%POSIX::SIGRT needs to be present and working. Given that %POSIX::SIGRT is
implemented as a tied hash, tied to POSIX::SigRT, this requires loading
POSIX to load POSIX::SigRT. POSIX::SigRT then uses POSIX::SigAction, but
not in TIEHASH, so presumably loading *that* could be deferred.

> >
> > I'm not advocating for that (nor am I planning to do the work),
> > but I'm supportive of that direction.
> Assuming that future I'd agree. But as long as that future hasn't
> arrived it seems a pointless worsening of the present to split the
> packages out. The splitting can easily be done as part of the commit
> which brings about the future anyhow.

Aye. I think it's just change until then, without actual progress.

Nicholas Clark

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