On 18 June 2021 19:33:09 BST, Rowan Tommins <rowan.coll...@gmail.com> wrote: >On 15/06/2021 11:53, Nikita Popov wrote: >> Feedback on the proposed deprecations is appreciated. 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. > > >To add some more "anecdata" to this, I just ran this to check for most >of the mentioned functions against the code base I work on (~800k lines > >of PHP, the oldest dating from 2002): > >ack --php >'date_sunrise|date_sunset|mb_check_encoding\(\)|get_class\(\)|get_parent_class\(\)|get_called_class\(\)|FILE_BINARY|FILE_TEXT|strptime|strftime|gmtstrftime|mhash|mysqli::init|filter.default|auto_detect_line_endings|ssl_method|FILTER_SANITIZE_STRING|FILTER_SANITIZE_STRIPPED|oci8.old_oci_close_semantics|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 >translated month name, the others are using various "human-friendly" >localized strings) > >Running the same command on the vendor directory, I find a further use >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 >looked at it in detail). > > >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. >* The codebase never needs to run on Windows, so portability is >completely irrelevant to me. >* 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 >strftime() and friends, IF there was a simple thread-safe replacement. >However, that's not mentioned in the RFC, and I'm not clear if it's >actually still the case. > > >Regards,
strftime is infected by thread unsafe locales, which is plenty of reason to deprecate it, with additional pro reasons for doing so being its disparate functionality among different os-es and libc's. Deprecation also doesn't mean removal, which won't happen until PHP 9, giving developers plenty of time to move to a saner threadsafe locale API based on intl/icu. cheers Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
