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

The future of POSIX in core

Thread Next
Mark Overmeer
August 30, 2011 13:06
The future of POSIX in core
Message ID:


In January/February of this year, I took the challenge to rewrite the
POSIX module. First I tried to get people interested and discuss the
general short-comings of the module, which sadly stranded in pointless
debates about setuid() incompatibilities:

Then, under the impression that patches were welcome, I spent a few days
for a full rewrite of the documentation, describing where the
1200 POSIX functions can be found in Perl. Without repeating myself:

Complete silence for three months followed. No-one bothered to tell
me that blead was closed and how to continue. I was wondered by this
attitude of core developers, really disappointing! However, beer at
YAPC::EU was a good healer so I grew some courage again. is a troublesome module. Aside from the manual page being
mistaken in countless places and the 150 separate single line autoloading
modules (which usually simply produce a "croak not implemented"), it is
on a stand-still for ages.

As a result, there are quite a number of packages on CPAN which IMHO
should have been part of the core POSIX. For instance, the module Paul
"LeoNerd" Evans mentioned today: POSIX::strptime. Also many modules
provided by Leon Timmermans: POSIX::RT::SharedMem, POSIX::RT::Timer,
SysV::SharedMem, ...  And more: POSIX::Wide, POSIX::RT::MQ,
POSIX::bsearch, etc etc.

Having all these great modules for small parts of the POSIX function set
separate has as big disadvantage that they do not get the same quality/
portability support as And do we want to rename into

I see the module move in either of these two directions:
  1) clean-up the module as part of perl-core.
  2) give POSIX a dual-life (Zelfram's request to dual-life Carp just
     comes in when I write this) and let it grow.

I propose to start-off with the cleaned-up POSIX as dual-life for
5.15. Then, invite the "CPAN" specialists of the missing compontents
to contribute their few lines of XS to the generic POSIX.xs, let it get
POSIX.xs/pm should only provide the bare minimum interface, mapped as
narrow as possible on the functions where it can. Fancy OO models and
such around these functions should not be part of this.

       Mark Overmeer MSc                                MARKOV Solutions                         

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About