Front page | perl.perl5.porters |
Postings from September 2011
Re: The future of POSIX in core
Thread Previous
|
Thread Next
From:
David Golden
Date:
September 2, 2011 05:06
Subject:
Re: The future of POSIX in core
Message ID:
CAOeq1c_MZXcUNbmdcYqCyA+aULc4w2NMKA5y6yQCV9RkYLaqPQ@mail.gmail.com
On Fri, Sep 2, 2011 at 7:47 AM, Mark Overmeer <mark@overmeer.net> wrote:
>> 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.
>
> Yeh, I wondered why he got away with it so easily, where my patches
> got totally ignored (what later got explained as "too late"). There are
> some changes in the output produced by that change and no-one seems to
> be bothered by that.
There was a very real timing issue in that Jan/Feb/March is when the
feature freeze for the next major release of Perl happens. Anything
sweeping is unlikely to make it in at that point.
As a separate note, I think you did yourself a dis-service by sending
the four patches in one because it increases the scope. If you had
submitted just the autosplit fix patch or re-submitted that one right
after the release of 5.14, I think it would have stood a bigger chance
of acceptance.
Please remember that people applying patches are essentially vouching
for the work of others and have a sense of accountability about what
things they accept. (At least I hope they do). The harder you make
that, the less likely thing are to be applied. That's even true of a
patch series where now a patch appliers has to make a distinction
between patches and enter into a debate over why some patches but not
others are acceptable. Not everyone is willing to take on that
responsibility all the time.
>> > 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"
>
> You may write documentation about everything what is *not* possible
> with Perl, but it is kind-of useless. Removing those from the docs fits
> better in the idea of "keeping Perl core as small as possible". And the
> documented list of "missing" is far from complete anyway.
Once documented, it should stay documented.
> tolower This is identical to the C function, except that it can apply
> to a single character or to a whole string. Consider using the
> "lc()" function, see "lc" in perlfunc, or the equivalent "\L"
> operator inside doublequotish strings.
>
> "This is identical, *but*". The ctype/tolower *macro* can only handle
> native characters. POSIX::tolower takes any string containing scalar,
> ignores whether it is utf8 or not, and then treats all bytes in it as
> 7-bit characters (ascii or ebcdic), returning a new scalar with the result.
> We do not have a single character data-type in Perl.
>
> Let's asume that we are not implementing the programming language C. Then,
> the documentation should, IMO, be reduced into:
>
> Legacy functions:
> tolower use build-in funtion lc()
This is a better example of where the existing POSIX functions should
probably warn and the documentation is best revised to say "don't use
this, use this other thing instead". I'm supportive of this kind of
change.
> Abigail did earlier protest against this change for a more valid reason:
> POSIX functions have no prototype. So, in reality, these two programs
> do differ now-adays:
>
> program 1:
> use POSIX 'exit';
> exit @rc;
>
> program 2:
> exit @rc;
>
> I consider the situation a bug, in both cases, because the documentation
> says that exit needs a scalar. But those bugs may show up with people.
Ugh. I'm on the fence about this sort of change.
-- David
Thread Previous
|
Thread Next