Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 8.1
On 28.06.2021 at 16:25, Nikita Popov wrote: > On Sat, Jun 19, 2021 at 1:04 AM Rowan Tommins > wrote: > >> On 18/06/2021 22:16, Derick Rethans wrote: >>> 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. >> >> >> I think you're probably right, but I think in general deprecations >> should be accompanied by much stronger migration instructions than >> "there's a class over here that probably does what you want if you kick >> it a bit". >> >> Like everything in ext/intl, IntlDateFormatter is rather complex, and >> the manual relies heavily on links to the ICU documentation, some of >> which are 404s. If you're saying my 276 uses of strftime() are "wrong", >> it would be nice to have a clear message of what is "right", and what I >> should do to "fix" them. >> > > Yeah, I definitely see the concern here. In my corpus, most uses of > strftime() are actually locale-independent and can be easily replaced by > DateTime::format(). I guess these are only being used because calling > strftime() is slightly more compact than calling DateTime::format(), which > requires creating a DateTime object first. A small handful use a locale > sensitive format, which would require IntlDateFormatter and its more > complex API. You could just call date(). :) > I believe the equivalent for %B would be something like this: > https://3v4l.org/1pNDi I think that would be %b. For %B you have to use "". > It doesn't help that the IntlDateFormatter API is > un-great and doesn't allow you to directly create a formatter for a pattern > without passing a number of irrelevant arguments. ACK. > Regards, > Nikita > > PS: I found this scary comment in the strftime() docs: > https://www.php.net/manual/en/function.strftime.php#104043 48 upvotes. d'oh Christoph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 8.1
On Sat, Jun 19, 2021 at 1:04 AM Rowan Tommins wrote: > On 18/06/2021 22:16, Derick Rethans wrote: > > 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. > > > I think you're probably right, but I think in general deprecations > should be accompanied by much stronger migration instructions than > "there's a class over here that probably does what you want if you kick > it a bit". > > Like everything in ext/intl, IntlDateFormatter is rather complex, and > the manual relies heavily on links to the ICU documentation, some of > which are 404s. If you're saying my 276 uses of strftime() are "wrong", > it would be nice to have a clear message of what is "right", and what I > should do to "fix" them. > Yeah, I definitely see the concern here. In my corpus, most uses of strftime() are actually locale-independent and can be easily replaced by DateTime::format(). I guess these are only being used because calling strftime() is slightly more compact than calling DateTime::format(), which requires creating a DateTime object first. A small handful use a locale sensitive format, which would require IntlDateFormatter and its more complex API. I believe the equivalent for %B would be something like this: https://3v4l.org/1pNDi It doesn't help that the IntlDateFormatter API is un-great and doesn't allow you to directly create a formatter for a pattern without passing a number of irrelevant arguments. Regards, Nikita PS: I found this scary comment in the strftime() docs: https://www.php.net/manual/en/function.strftime.php#104043
Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 8.1
On 18/06/2021 22:16, Derick Rethans wrote: 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. I think you're probably right, but I think in general deprecations should be accompanied by much stronger migration instructions than "there's a class over here that probably does what you want if you kick it a bit". Like everything in ext/intl, IntlDateFormatter is rather complex, and the manual relies heavily on links to the ICU documentation, some of which are 404s. If you're saying my 276 uses of strftime() are "wrong", it would be nice to have a clear message of what is "right", and what I should do to "fix" them. If the alternative is definitely there, and the deprecation is accompanied by an effort to document it clearly, then my objection goes away. Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 8.1
On 18 June 2021 19:33:09 BST, Rowan Tommins 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
Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 8.1
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, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 8.1
Hello, Le Tue, 15 Jun 2021 12:53:47 +0200, Nikita Popov a écrit : > 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. I use get_called_class() a lot, which is way clearer than static::class as the name describe what it does. I think I am not the only one as I find occurences of it in several projects I have in my vendor/ folder, like rector and codesniffer (not the latest version through, maybe they changed it). Forcing people to use static::class will make them have a better understanding/instinct of what static:: does, but is that worth forcing a change on a working code for something less descriptive, I’m not convinced. Côme -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
