Front page | perl.perl5.porters |
Postings from September 2011
On Sat, Sep 03, 2011 at 04:11:45AM +0200, Aristotle Pagaltzis wrote: > * David Golden <xdaveg@gmail.com> [2011-09-02 18:20]: > > On Fri, Sep 2, 2011 at 11:05 AM, Nicholas Clark <nick@ccl4.org> wrote: > >>> I have no objection to splitting out POSIX::SigAction and > >>> POSIX::SigRT into separate .pm files that are used by POSIX.pm. > >>> (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 POSIX.pm 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 ClarkThread Previous | Thread Next