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

Re: The future of POSIX in core

Thread Previous | Thread Next
David Golden
September 2, 2011 03:59
Re: The future of POSIX in core
Message ID:
As I understand it, the original motivation for updating 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 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

Beyond that, all the proposed changes seem like personal design/style
preferences imposed upon the existing 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 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.

-- David

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