develooper 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


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About