develooper Front page | perl.perl5.porters | Postings from January 2011

Re: Time to update POSIX.pm?

Thread Previous | Thread Next
From:
Aristotle Pagaltzis
Date:
January 30, 2011 06:11
Subject:
Re: Time to update POSIX.pm?
Message ID:
20110130141058.GL5522@klangraum.plasmasturm.org
* Jesse Vincent <jesse@fsck.com> [2011-01-30 01:20]:
> Code modernization is good. I'd love to see a version of this
> that actually compiles and passes perl's tests. (This version
> does not, even after adding a $sigil to VERSION.)

I refactored POSIX.pm once to gets rid of Autoloader in favour of
a custom lazy-compile scheme (storing the bodies in a hash and
`eval`ing them in AUTOLOAD), but never got around to posting the
patches.

What I had really hoped to do was cut its memory footprint by
rewriting the importing, but AUTOLOAD turned out to be a problem.
It needs function stubs to work properly (`sub foo;`) and they
end up costing a large fraction of its full memory cost. It isn’t
possible to postpone them, though, because `use POSIX` relies on
exporting the stubs and letting AUTOLOAD pick up the slack if any
of them is called. Unfortunately there is no way to find out what
name a function was called with, so I can’t think of a way around
this.

I also thought of dropping Exporter entirely and rewriting export
based on a single table (instead of a tags hash, a generated list
of default exports, plus a list of optional exports). However
Exporter supports a whole bunch of features to select particular
imports. How much of that would I have to reimplement? Are the
negation and pattern features ever really used? But unfortunately
POSIX.pm happens to be the one module where I can imagine them
being of use, since the list of default exports is huge and even
specific tags still export a wheelbarrowful of functions.

I did however clean up the code quite thoroughly by the end. As
far as I know, tests all still pass as well.

And now that I think about it, I could optionally use prefork.pm
to compile everything at load time if that’s enabled. That would
address Markov’s use case. (Optionally only since it’s not in
core. It already monkey-patches CGI.pm, so I could send Alias a
patch to do the same for the patched POSIX.pm, but then it would
have to check for a sufficiently recent POSIX.pm and it’s just
generally a bad scene. Alternatively it could be non-optional in
POSIX.pm and prefork.pm could pulled into core, if Alias is fine
with that too. It’s small, addresses a common need, and has been
stable for years.)

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

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