On Wed, Aug 31, 2011 at 10:38:19PM +0200, Mark Overmeer wrote: > He offers to add any library test to the configuration phase of Perl > itself... but it might be better to move all checks which are only > needed for POSIX.pm into the dual-lifed POSIX itself: that would be > more flexible when we extend the support with a few hundred more > functions. Do we actually want a few hundred more POSIX functions *in core*? Stepping back: Jesse's stated goal, around which I think there has been broad consensus, is that the core should concentrate on facilitating the installation of more modules from CPAN. There's reasonable consensus that it should also be possible to use this "minimal core" to build any number of fuller task-specific distributions, of which the current "classic core" is just one. Providing a full interface to POSIX:2008 is laudable, and should be available. But having it in the core doesn't in itself aid installing modules, and hence contradicts the goal of a minimal core. Given that it would cause insane breakage to remove the current POSIX module from core as it would break so much [not sure how to do a popularity contest for it, but I suspect that POSIX::_exit() is one of the most common uses] isn't an alternative more in keeping with the idea of a minimal core to 0: declare that the core POSIX is effectively a legacy module 1: that it supports (I infer) the 1997 POSIX.1 functionality 2: document that POSIX 2008 support is available on CPAN 3: provide modern POSIX 2008 support as one (or more) CPAN modules ie consider that the API of the current POSIX is pretty slushy [documentation and implementation fixes obviously still most welcome] and that the future of good POSIX support lies on CPAN. Nicholas ClarkThread Previous | Thread Next