Front page | perl.perl5.porters |
Postings from September 2011
On Fri, Sep 02, 2011 at 10:27:18AM -0400, David Golden wrote: > On Fri, Sep 2, 2011 at 10:04 AM, Mark Overmeer <mark@overmeer.net> 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 POSIX.pm. > 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 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. 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 needed. > 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 cone. 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 ClarkThread Previous | Thread Next