Front page | perl.perl5.porters |
Postings from January 2012
On Mon, Jan 02, 2012 at 03:24:08PM +0200, Leon Timmermans wrote: > On Mon, Jan 2, 2012 at 3:22 AM, David Golden <xdaveg@gmail.com> wrote: > > There is so much in POSIX.pm that doesn't work portably or that the > > docs say shouldn't actually be used, that I don't see any reason to > > deprecate this particular piece. If it's really dangerous, the doc > > warning could be strengthened, possibly by referring them to perlipc > > which discusses the use of safe signals (and potential risks of unsafe > > signals). > > My real problem with it is that I have no idea why anyone would want > to use this. There's absolutely nothing you can't do without it. It's > a poorly written wrapper class around previously existing POSIX > functionality. Get it while it's hot. Or at least while "I Aten't Dead": http://codesearch.google.com/#search/&q=POSIX::SigRt&type=cs For the next 12 days Google Codesearch will report that *nothing* uses it. After which, Google becomes a bit less useful for me. Have Bing or Yahoo! written a codesearch yet? > > Put differently, does the ability of a user to enable unsafe signals > > actually interfere with something else that needs doing/fixing? (And > > if so, what about PERL_SIGNALS?) Or is the core of your objection a > > stylistic one? I completely respect a stylistic objection (I might > > even agree with it), but don't think that clears the bar for > > deprecation, given the options we give people for shooting themselves > > in the foot already. > > Right now it doesn't even enable people to shoot themselves in the > foot, since it's not documented how to do that! I don't see merit in keeping it. Unlike most other things in POSIX 1: it's easy to be confident about the user base 2: which is roughly zero 3: it's easy to provide a transitional warning 4: it's easy to provide a replacement implementation So the cost of taking it out is small. Couple that with it's not actually useful, and it's not documented, and the small cost of taking it out is less than the small gain from doing so. (Which I'd contrast with, say, the cost of taking out code from sdbm.h, which is probably dead, but it's hard to be sure) Nicholas ClarkThread Previous | Thread Next