Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114966
Date: Fri, 18 Jun 2021 22:16:49 +0100
User-Agent: K-9 Mail for Android
In-Reply-To: <ff9f11a0-d019-f3a4-594a-0a09e05a2c01@gmail.com>
References: <CAF+90c9crhPpSMcTx-ozGo0LGjNuBU43e8fiK_=PJMU6iTHNmw@mail.gmail.com> <CAF+90c9MFwjpgmJ97JzmfA57XOdDVCS96P_SoVkBNrLEORVozg@mail.gmail.com> <ff9f11a0-d019-f3a4-594a-0a09e05a2c01@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
To: internals@lists.php.net,Rowan Tommins <rowan.collins@gmail.com>
Message-ID: <4D4B548F-5F51-480B-AECF-FC2DB586F396@php.net>
Subject: Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 8.1
From: derick@php.net (Derick Rethans)

On 18 June 2021 19:33:09 BST, Rowan Tommins <rowan=2Ecollins@gmail=2Ecom> w=
rote:
>On 15/06/2021 11:53, Nikita Popov wrote:
>> Feedback on the proposed deprecations is appreciated=2E Personally, the
>two
>> I'm unsure about are "get_class(), get_parent_class() and
>> get_called_class() without argument" which are mostly stylistic in
>nature,
>> and "strftime() and gmtstrftime()", where the non-portability issues
>are
>> possibly not so bad that a disruption of existing users is
>worthwhile=2E
>
>
>To add some more "anecdata" to this, I just ran this to check for most=20
>of the mentioned functions against the code base I work on (~800k lines
>
>of PHP, the oldest dating from 2002):
>
>ack --php=20
>'date_sunrise|date_sunset|mb_check_encoding\(\)|get_class\(\)|get_parent_=
class\(\)|get_called_class\(\)|FILE_BINARY|FILE_TEXT|strptime|strftime|gmts=
trftime|mhash|mysqli::init|filter=2Edefault|auto_detect_line_endings|ssl_me=
thod|FILTER_SANITIZE_STRING|FILTER_SANITIZE_STRIPPED|oci8=2Eold_oci_close_s=
emantics|odbc_result_all'
>
>-oh | sort | uniq -c
>
>
>The result is this:
>
>1 FILTER_SANITIZE_STRING (which definitely looks dubious)
>1 auto_detect_line_endings (which is commented out anyway)
>276 strftime (nearly half are using the format string "%B" to get a=20
>translated month name, the others are using various "human-friendly"=20
>localized strings)
>
>Running the same command on the vendor directory, I find a further use=20
>of strftime (in nusoap, which should probably just be using date()) and
>
>a handful of uses of get_class() and get_called_class() (which I
>haven't=20
>looked at it in detail)=2E
>
>
>If it went to a vote now, I would vote "no" on strftime:
>
>* Looking at the proposed replacement, IntlDateFormatter, the API seems
>
>to be much more complex and completely incompatible, so migration would
>
>be painful=2E
>* The codebase never needs to run on Windows, so portability is=20
>completely irrelevant to me=2E
>* There is a note on the manual page for setlocale() warning that it is
>
>not thread-safe, which if true would be a stronger reason to deprecate=20
>strftime() and friends, IF there was a simple thread-safe replacement=2E=
=20
>However, that's not mentioned in the RFC, and I'm not clear if it's=20
>actually still the case=2E
>
>
>Regards,

strftime is infected by thread unsafe locales, which is plenty of reason t=
o deprecate it, with additional pro reasons for doing so being its disparat=
e functionality among different os-es and libc's=2E

Deprecation also doesn't mean removal, which won't happen until PHP 9, giv=
ing developers plenty of time to move to a saner threadsafe locale API base=
d on intl/icu=2E

cheers
Derick