Front page | perl.perl5.porters |
Postings from September 2011
Re: The future of POSIX in core
Thread Previous
|
Thread Next
From:
Nicholas Clark
Date:
September 2, 2011 02:54
Subject:
Re: The future of POSIX in core
Message ID:
20110902095356.GS23881@plum.flirble.org
On Fri, Sep 02, 2011 at 10:39:33AM +0200, Mark Overmeer wrote:
> * Nicholas Clark (nick@ccl4.org) [110901 20:08]:
> > 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
>
> @0: even when declaring it legacy, it still needs a lot of changes,
> for instance to get rit of 250 autoloaded files in the distribution
> of which many say "not implemented". So:
>
> @1: POSIX.pm is by far not POSIX.1 1997! It has implemented only a
> few (about 50) of its functions. The manual-page is very broken, as
> I have shown various times before. And I do not believe that removing
> things like "wide-character" support from a POSIX-in-core would
> disturb anyone.
So what whas the POSIX standard in 1994?
Because that's when the code dates from.
One would not think that changing the output of perl -v would disturb
anyone, but we got complaints because at least one deployed system was
relying on it, for some sort of probe.
The maintenance burden of the XS code for all these strange things is
near zero. Most are unchanged since 5.000. Leaving them in breaks nothing.
Taking them out has the potential to break something.
*Every* change has the potential to break something. The product of a lot
of small independent probabilities of failure rapidly becomes a reasonable
certainty of *something* failing - ie if we make a lot of small "this will
hurt no-one" changes, it ends up being a statistical certainty that we
will hurt someone.
So even small changes have to be considered on balance, because we make
so many of them.
I'm not comfortable that taking these things out is worth it.
> @2: after POSIX 2008, we will get extensions, like POSIX 2015. It is
> inconvenient to rename modules, so in the long run we would get stuck
> to POSIX::2008 to support the 2015 version... I think we need a better
> name for it. Or we may do: POSIX::2015 extends POSIX::2008 extends
> POSIX::2015.
So name it after the subsections of the POSIX spec?
That avoids it being named "POSIX", and avoids having one monolithic module.
> @3: yes.
>
> > 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.
>
> The very large patches, which I have sent to this list, can be a good
> start of the suggested changes.
>
> May I suggest to do the following:
> (step 6 to 8 may mildly break things, so need further discussion on
> the list)
>
> 1. remove the autoloading
After you first raised the issue, Aristotle had also offered patches to do
this alone [no prototype changes, same usage() checking]. I wrote quite a
lot of tests, and rejigged and applied his patches, because there seemed to
be consensus that you're dead right on this one, and his code offered a very
elegant solution to just this.
POSIX.pm in blead now half the size. It wouldn't have changed if you hadn't
raised awareness of how bad it is. Thanks.
> 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.
> 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"
> 4. let the documentation say: this legacy module provides a small
> subset of POSIX 1997, see POSIX::??? on CPAN.
I suspect it's a subset of one or more sections of POSIX 1988 and 1993
The POSIX module dates from 1994, but I'm not sure if some of it is a
rewrite of something perl4-era, hence possibly from somewhat earlier.
> 5. refrase all the lies from the documentation. "is the same as"
> this means: full rewrite of the man-page
"is the same as" is always risky, because everyone has a different man
page (or none, so they read something random on the Internet) to base their
expectations off. Documenting what it actually does is useful.
[Your set that "may mildly break things"]
> 6. remove 40 functions which simply forward to core perl functions
> with the same name, for instance chdir(), but avoid errors from
> being reported when people explicitly import those.
"avoid errors from being reported" means that you're proposing that working
code such as:
$ ./perl -Ilib -e 'use POSIX "chdir"; chdir('t');'
becomes a runtime error:
$ ./perl -Ilib -e 'use POSIX "chdir"; chdir('t');'
chdir is not a valid POSIX macro at -e line 1
not even a compiletime error.
It would cause less breakage to have a compiletime error.
As currently formulated, this is a stupid suggestion.
I have considered my wording carefully, and I'm sticking to 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.
> 8. move to CPAN things which have a very specific/limited use,
> for instance POSIX::Termios... or do we really need Text::Termcap
> and Term::Cap in core?
We've removed 5 (IIRC) no-experimental modules from core now, all of which
were not used, or should-not-be-used.
Any further suggestions are on what might go is turning out to be extremely
controversial. Term::Cap and Pod::Text::Termcap are in core, Text::Termcap
doesn't exist. I'm not sure what you mean by referencing them here - that
they should go, or that POSIX::Termios is very limited without them?
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.
> the endless debates when touching pet subjects of certain core developers.
> Those may consume all the time I have.
I think it's fair to say that the pet subject of most core developers is
"not breaking things". As in trying to achieve whatever else it was they
actually wanted without inadvertently breaking something, often something
they weren't aware of.
Proposing changes to a situation that would be quite sane if starting
afresh, but are likely to cause breakage simply because they are changes to
existing code is going to upset people - the people who end up having to
field the irate bug reports sent to perlbug about "you broke my code".
Nicholas Clark
Thread Previous
|
Thread Next