Front page | perl.perl5.porters |
Postings from September 2011
Re: The future of POSIX in core
Thread Previous
|
Thread Next
From:
Nicholas Clark
Date:
September 2, 2011 07:08
Subject:
Re: The future of POSIX in core
Message ID:
20110902140810.GZ23881@plum.flirble.org
On Fri, Sep 02, 2011 at 06:59:27AM -0400, David Golden wrote:
> As I understand it, the original motivation for updating POSIX.pm were these:
>
> * autosplit is horribly inefficient
> * Good POSIX extensions on CPAN should be in perl core and there's no
> easy way to do so
* the documentation is "less than awesome", for various large values of less.
> I think the autosplit is now fixed, right? Excellent!
>
> Does modularizing POSIX implementation (while leaving POSIX.pm as a
> compatibility interface to submodules) help with the second? If so,
> I'm in favor. If not, I'm still not clear what the proposed answer
> is.
I'm not sure that it does.
> Beyond that, all the proposed changes seem like personal design/style
> preferences imposed upon the existing POSIX.pm API (includng @EXPORT)
> and I don't think the originally stated issues justify such changes.
I wouldn't say it's personal design/style preferences. Mostly it's that
* the existing interface is bad
* if we were doing it again, we'd do it differently
with complete consensus on both at the bullet point level, and mostly
agreement on details of how on the latter,
*but*
considerable disagreement on the right level of trade off between "clean it
up" and "might break something out there"
> Other specific responses follow.
>
> >> 2. remove all functions which croak in "not implemented"
> >
> > The implementation of these is now on demand, 1 line per function. The cost
> > of keeping them is low.
> >
> > Even though they don't do anything, I'm not sure *why* I'm not comfortable
> > with removing them. I think it's because they *are* part of @EXPORT, the
> > public API, and it feels wrong to either
> >
> > a: change @EXPORT
> > b: have something in @EXPORT that doesn't actually get exported.
>
> Agreed, with the caveat that the functions don't have to live in
> POSIX.pm as long as POSIX::import() can provide them by default or on
> demand from sub-modules.
Which it still does. Previously via AutoLoader (in that the rarely-to-never
used functions sit on disk, taking up no memory), now via a custom AUTOLOAD
routine (which I suspect means that they actually take up more memory now)
I think that Aristotle's code was the simplest possible way to keep the
functions available "on demand". One could remove them, at which point
trying to use them will generate a different error message
$ ./perl -Ilib -MPOSIX -e 'POSIX::fclose()'
Use method IO::Handle::close() instead of POSIX::fclose() at -e line 1
$ ./perl -Ilib -MPOSIX -e 'POSIX::frobnicate()'
frobnicate is not a valid POSIX macro at -e line 1
but it would
a: take code (and work) to list the removed functions so that the AUTOLOAD
routine produced a more correct
"Undefined subroutine POSIX::frobnicate() called"
message, at which point we're not much simpler than where we are with the
"helpful" 1994 messages.
b: removing them from EXPORT actually changes parsing
$ ./perl -Ilib -MPOSIX -MO=Deparse -e 'print POSIX::frobnicate foo'
print 'foo'->POSIX::frobnicate;
-e syntax OK
$ ./perl -Ilib -MPOSIX -MO=Deparse -e 'print POSIX::fclose foo'
print POSIX::fclose('foo');
-e syntax OK
I'm not sure what that might trip up, but the fact remains that it might.
[related, and on my mind is that adding () prototypes to Fcntl constants
happened to break previously working-by-chance code in Tie::File and
File::Slurp. There's always something to surprise you]
I can't see a way to load on-demand this stuff without actually making the
code more complex than it currently is. This doesn't rule it out, but I'm
not betting on anyone producing a solution. Happy to be proved wrong. Not
expecting it in this case.
> > It would be better if the POSIX subclasses were in separate modules.
> > But historically there were not, hence have been loaded via use POSIX;
> > So it's not clear how to do this without breaking things.
>
> As long as "use POSIX" or "use POSIX qw/function1 function2/" can load
> the appropriate subclass, I'm not opposed to breaking it up into
> separate modules if that is beneficial in some way.
I can't (yet) see a good way to do this.
Nicholas Clark
Thread Previous
|
Thread Next