On Thu, Feb 3, 2011 at 4:23 PM, Mark Overmeer <solutions@overmeer.net> wrote: > Actually, the setuid() was only a minor detail. I think that solution > is quite simple: the module is named POSIX, so should follow the > standard as close as possible (which is already the case). You do not > have to compare different OSes to see what functionality should be in > there. POSIX is big, I like modules small. CPAN can handle this. There are a dozen modules in the POSIX:: namespace already and there's plenty of space left there. Besides, in a lot of cases a more Perlish interface is more useful than a raw C-like interface anyway. In some cases the latter may even be useless entirely. > Is it useful to provide a function which croaks? (when 900 other, > also missing functions, are just unknown) No, I don't think so (though trivial implementations like your atoi are equally useless IMO). > . remove the autoloading: it slows everything down with 150 files > of each about 12 lines. IMO AutoLoader should be phased in general. It's the wrong trade-off for almost any module nowadays, even POSIX.pm > Some regressions are permitted between major perl releases. Is this > too much? I'm afraid so. POSIX is relied upon a lot, we can't deprecate stuff that easily. > IMO, the POSIX.pod manual should become the starting point for > people with little Perl knowledge but a lot of POSIX experience, > for instance all C programmers... > > I think we should try to propose implementations for all POSIX > functions or explain why they are not needed. Mainly in a table > with explanation I rather like this idea. > So: above is my wish. I would like to hear your (and other peoples) > feeling towards implementing one or more of these changes before I > produce patch-sets for them. > > This could be ready within a week from now (simply removing most code, > rewrite of the manpage is the real task) But I can do other things with > my time if nobody cares... I'm not sure this should happen before 5.14, given feature freeze is rather soon and some of the things you're suggesting are probably contentious. Improving documentation is always good though. LeonThread Previous | Thread Next