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 07:08
Re: The future of POSIX in core
Message ID:
On Fri, Sep 02, 2011 at 06:59:27AM -0400, David Golden wrote:
> As I understand it, the original motivation for updating 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 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 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,


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
> 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 Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About