Front page | perl.perl5.porters |
Postings from September 2011
As I understand it, the original motivation for updating POSIX.pm were these: * autosplit is horribly inefficient * Good POSIX extensions on CPAN should be in perl core and there's no easy way to do so I think the autosplit is now fixed, right? Excellent! Does modularizing POSIX implementation (while leaving POSIX.pm as a compatibility interface to submodules) help with the second? If so, I'm in favor. If not, I'm still not clear what the proposed answer is. Beyond that, all the proposed changes seem like personal design/style preferences imposed upon the existing POSIX.pm API (includng @EXPORT) and I don't think the originally stated issues justify such changes. Other specific responses follow. >> 2. remove all functions which croak in "not implemented" > > The implementation of these is now on demand, 1 line per function. The cost > of keeping them is low. > > Even though they don't do anything, I'm not sure *why* I'm not comfortable > with removing them. I think it's because they *are* part of @EXPORT, the > public API, and it feels wrong to either > > a: change @EXPORT > b: have something in @EXPORT that doesn't actually get exported. Agreed, with the caveat that the functions don't have to live in POSIX.pm as long as POSIX::import() can provide them by default or on demand from sub-modules. >> 3. remove documentation for all functions which are not really >> implemented or documented as not possible to implement. > > Remove totally? Or document a list of "not really implemented" and > "not possible to implement" +1 -- better to document what isn't implemented than to just hide it. >> 7. remove stuff which no-one in its right mind should use: isalnum, >> wide character functions. > > But people do do this. Moreover, sensible people inherit crazy spaghetti balls > of code that keep working, where there is no time (or business reason) to > change the code. This sort of change would punish people. Agreed. "no one should use" is too subjective. I'm not opposed to adding warnings to particularly ugly thing that aren't likely to work the way people expect if there are such functions, but I haven't seen the case made for it, yet. > It would be better if the POSIX subclasses were in separate modules. > But historically there were not, hence have been loaded via use POSIX; > So it's not clear how to do this without breaking things. As long as "use POSIX" or "use POSIX qw/function1 function2/" can load the appropriate subclass, I'm not opposed to breaking it up into separate modules if that is beneficial in some way. -- DavidThread Previous | Thread Next