Front page | perl.perl5.porters |
Postings from January 2011
* 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