Re: [PHP-DEV] [RFC] Deprecations for PHP 8.1
On Wed, Jun 30, 2021 at 5:30 AM Stephen Reay wrote: > > > > On 29 Jun 2021, at 02:28, Jan Ehrhardt wrote: > > > > Nikita Popov in php.internals (Mon, 22 Mar 2021 10:24:51 +0100): > >> Hi internals, > >> > >> It's time for another deprecation RFC: > >> https://wiki.php.net/rfc/deprecations_php_8_1 > > > > FWIW, a quick search returned these results. > > > > ADOdb still uses strftime() > > https://adodb.org/dokuwiki/doku.php > > > > 2 plugins of Matomo (formerly Piwik) still uses strftime in > > Login/PasswordResetter.php and RssWidget/RssRenderer.php > > > > The simplepie library still uses strftime: > > > https://github.com/simplepie/simplepie/blob/717d9ea4bf1a8533d5a26128b7acc1598388ce66/library/SimplePie/Item.php#L882 > > > > Limesurvey still uses strftime, in the ADOdb functions and in the > kcfinder > > functions: > > > https://github.com/LimeSurvey/LimeSurvey/blob/6437c998731e1e79da24c394ef205444cfa75cdf/third_party/kcfinder/core/class/browser.php#L784 > > > > Drupal 7 uses strftime in the date module and in the views module: > > https://www.drupal.org/project/date > > See date/date_api/date_api_sql.inc > > https://www.drupal.org/project/views > > See views/includes/handlers.inc > > > > Drupal 8 uses strftime. Example: > > > https://api.drupal.org/api/drupal/core!modules!views!src!Plugin!views!query!Sql.php/function/Sql%3A%3AgetDateFormat/8.2.x > > -- > > Jan > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: https://www.php.net/unsub.php > > > > (Bah! Sending again to the list, because me stupid) > > I’m sure some of those are legitimate - but to my eye, the Drupal 8 > example at least, is _not_ using `strftime` in *PHP*. > > I believe it’s making use of the `strftime` function in SQLite. > Was surprised to see Drupal in the list but that makes sense. Confirmed those D7 views and date modules are doing the same thing and using the sqlite function, not PHP's. This made me suspicious about adodb since it is also doing database abstraction and searching their github source the best I can tell all the calls in it are _also_ to the sqlite function, not php's.
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.1
On Sat, Apr 24, 2021 at 7:38 PM Rowan Tommins wrote: > On 22/03/2021 09:24, Nikita Popov wrote: > > It's time for another deprecation RFC: > > https://wiki.php.net/rfc/deprecations_php_8_1 > > > I have added another proposal to this list: the 'ssl_method' option to > the SoapClient constructor, which in practice only allows you to force > use of SSLv3. A more flexible alternative is available via stream > context options. > > > https://wiki.php.net/rfc/deprecations_php_8_1#ssl_method_option_to_soapclient_constructor > > Note that both the SoapClient-specific and stream context versions of > this are currently missing documentation, which I am working on improving. > Just want to note that there is an outstanding PR that adds newer methods to SOAP ssl_method: https://github.com/php/php-src/pull/5518 That would be a possible alternative to deprecation. Though given how there are now many PHP versions that don't support this, deprecating and making people use the standard stream context approach does seem sensible. Regards, Nikita
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.1
> On 29 Jun 2021, at 02:28, Jan Ehrhardt wrote: > > Nikita Popov in php.internals (Mon, 22 Mar 2021 10:24:51 +0100): >> Hi internals, >> >> It's time for another deprecation RFC: >> https://wiki.php.net/rfc/deprecations_php_8_1 > > FWIW, a quick search returned these results. > > ADOdb still uses strftime() > https://adodb.org/dokuwiki/doku.php > > 2 plugins of Matomo (formerly Piwik) still uses strftime in > Login/PasswordResetter.php and RssWidget/RssRenderer.php > > The simplepie library still uses strftime: > https://github.com/simplepie/simplepie/blob/717d9ea4bf1a8533d5a26128b7acc1598388ce66/library/SimplePie/Item.php#L882 > > Limesurvey still uses strftime, in the ADOdb functions and in the kcfinder > functions: > https://github.com/LimeSurvey/LimeSurvey/blob/6437c998731e1e79da24c394ef205444cfa75cdf/third_party/kcfinder/core/class/browser.php#L784 > > Drupal 7 uses strftime in the date module and in the views module: > https://www.drupal.org/project/date > See date/date_api/date_api_sql.inc > https://www.drupal.org/project/views > See views/includes/handlers.inc > > Drupal 8 uses strftime. Example: > https://api.drupal.org/api/drupal/core!modules!views!src!Plugin!views!query!Sql.php/function/Sql%3A%3AgetDateFormat/8.2.x > -- > Jan > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > (Bah! Sending again to the list, because me stupid) I’m sure some of those are legitimate - but to my eye, the Drupal 8 example at least, is _not_ using `strftime` in *PHP*. I believe it’s making use of the `strftime` function in SQLite. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.1
Hi Nikita, Very good list, thank you. The only one I am totally not sure about is image(filled)polygon $numpoints. There are really tons of codes out there using it. There is little to no gain to remove it but create a load of 1st level support requests to many packages and applications. A deprecation notice in this case, in a not so well configured php, will break the image display. I would rather make a documentation deprecation. Once we move to namespace and objects for this, it is simple to provide a clean alternative (addPoint(s), etc). Best, On Mon, Mar 22, 2021 at 4:25 PM Nikita Popov wrote: > > Hi internals, > > It's time for another deprecation RFC: > https://wiki.php.net/rfc/deprecations_php_8_1 > > This is a collection of minor deprecations that various people have put > together over the last ~2 years. This RFC was formerly targeted at PHP 8.0, > but was delayed to PHP 8.1 to reduce the amount of changes necessary for > PHP 8.0 compatibility. > > As usual, each deprecation will be voted in isolation. > > As we're still early in the release cycle, it's still possible to add > additional deprecation candidates, given reasoning for the deprecation, as > well as available alternatives. > > Of course, if there are compelling technical reasons why something should > not be deprecated, we can move things into the "Removed from this proposal" > section, in which case it will serve as documentation why some > functionality should not deprecated. > > Regards, > Nikita -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.1
On Tue, Jun 15, 2021, at 10:59 PM, Mike Schinkel wrote: > > On Jun 15, 2021, at 6:53 AM, Nikita Popov wrote: > > > > As we're moving closer to feature freeze, I'd like to close down this RFC > > to further additions, and move towards voting. > > > > 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 just opened one client project and searched and found 52 usages for > get_called_class(), no usages for the other two. Just one project. > > This was a WordPress project which means many plugins from any > different developers. > > Would deprecating get_called_class() w/o a parameter be important > enough to cause so much BC breakage? > > -Mike TYPO3 data points: get_called_class(): Used once, in TYPO's enumeration class. (Which likely will die in v12 because we'll have real enumerations, I hope.) get_class(): Used about a dozen times in Doctrine, but not in TYPO3 itself. get_parent_class(): Used once in Codeception, the acceptance testing framework strftime(): Unused gmtstrftime(): Unused --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.1
> On Jun 15, 2021, at 6:53 AM, Nikita Popov wrote: > > As we're moving closer to feature freeze, I'd like to close down this RFC > to further additions, and move towards voting. > > 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 just opened one client project and searched and found 52 usages for get_called_class(), no usages for the other two. Just one project. This was a WordPress project which means many plugins from any different developers. Would deprecating get_called_class() w/o a parameter be important enough to cause so much BC breakage? -Mike
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.1
thanks > Not going to include a deprecation proposal as part of this RFC though -- from past discussions, the topic was controversial, so I don't want to include it this late in the process. That's fine by me. > the topic was controversial indeed it is/was (at least on Reddit) On Tue, 15 Jun 2021 at 14:24, Nikita Popov wrote: > On Tue, Jun 15, 2021 at 12:48 PM Hans Henrik Bergan > wrote: > >> i don't like this part of the RFC: >> >> > There's a number of bug reports related to this. From what I understand, >> the core problem here is not that the ISO8601 format is *wrong*, it's just >> one of multiple legal ISO-8601 formats. As DateTime formats always refer >> to >> a specific format, not a set of multiple possible ones, there doesn't seem >> to be anything actionable here. >> >> - this is wrong, DateTime::ISO8601 *is* illegal in ISO8601. >> quoting ISO8601:2004 section 4.3.3: >> >> > For reduced accuracy, decimal or expanded representations of date and >> time of day, any of the representations in 4.1.2 (calendar dates), 4.1.3 >> (ordinal dates) or 4.1.4 (week dates) followed immediately by the time >> designator [T] may be combined with any of the representations in 4.2.2.2 >> through 4.2.2.4 (local time), 4.2.4 (UTC of day) or 4.2.5.2 (local time >> and >> the difference from UTC) provided that (...skipped stuff...) d) the >> expression shall either be completely in basic format, in which case the >> minimum number of separators necessary for the required expression is >> used, >> or completely in extended format, in which case additional separators >> shall >> be used in accordance with 4.1 and 4.2. >> >> DateTime::ISO8601 does exactly what part "d" says isn't legal, >> 1970-01-01T01:00:00 is extended format, and +0100 is basic format, >> breaking >> the "the expression shall either be completely in basic format, in which >> case the minimum number of separators necessary for the required >> expression >> is used, or completely in extended format" -part. " 1970-01-01T01:00:00" >> is >> legal extended format but illegal basic format, and "+0100" is legal basic >> format but illegal extended format, and mixing the 2 isn't legal. >> > > Thanks for the reference. I've removed the mention of DateTime::ISO8601 > from the RFC to make sure that the RFC text doesn't make any incorrect > statements. Not going to include a deprecation proposal as part of this RFC > though -- from past discussions, the topic was controversial, so I don't > want to include it this late in the process. > > Regards, > Nikita > > >> On Tue, 15 Jun 2021 at 12:33, Christoph M. Becker >> wrote: >> >> > On 23.03.2021 at 06:04, Stanislav Malyshev wrote: >> > >> > >> t fopen mode >> > > >> > > I'm afraid there's - despite the warning - a bunch of code for Windows >> > > that relies on "t" and I don't think we should be breaking it. Is >> there >> > > a good reason to drop this mode? >> > >> > I don't see much need for 't' mode nowadays. Even Notepad properly >> > handles LF fine for some years now. It's not really bad, if it can be >> > explicitely specified. However, deprecating 't' mode would pave the way >> > to sometime change shell_exec() to no longer use 't' mode, what is a >> > footgun when dealing with binary data. So when using the backtick >> > operator on Windows, you always need to keep that in mind. From my >> > experience, 't' mode causes more harm than good. >> > >> > And if there is really the need for LF conversion, that still can be >> > done with an explicit filter. >> > >> > -- >> > Christoph M. Becker >> > >> > -- >> > PHP Internals - PHP Runtime Development Mailing List >> > To unsubscribe, visit: https://www.php.net/unsub.php >> > >> > >> >
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.1
On Tue, Jun 15, 2021 at 12:48 PM Hans Henrik Bergan wrote: > i don't like this part of the RFC: > > > There's a number of bug reports related to this. From what I understand, > the core problem here is not that the ISO8601 format is *wrong*, it's just > one of multiple legal ISO-8601 formats. As DateTime formats always refer to > a specific format, not a set of multiple possible ones, there doesn't seem > to be anything actionable here. > > - this is wrong, DateTime::ISO8601 *is* illegal in ISO8601. > quoting ISO8601:2004 section 4.3.3: > > > For reduced accuracy, decimal or expanded representations of date and > time of day, any of the representations in 4.1.2 (calendar dates), 4.1.3 > (ordinal dates) or 4.1.4 (week dates) followed immediately by the time > designator [T] may be combined with any of the representations in 4.2.2.2 > through 4.2.2.4 (local time), 4.2.4 (UTC of day) or 4.2.5.2 (local time and > the difference from UTC) provided that (...skipped stuff...) d) the > expression shall either be completely in basic format, in which case the > minimum number of separators necessary for the required expression is used, > or completely in extended format, in which case additional separators shall > be used in accordance with 4.1 and 4.2. > > DateTime::ISO8601 does exactly what part "d" says isn't legal, > 1970-01-01T01:00:00 is extended format, and +0100 is basic format, breaking > the "the expression shall either be completely in basic format, in which > case the minimum number of separators necessary for the required expression > is used, or completely in extended format" -part. " 1970-01-01T01:00:00" is > legal extended format but illegal basic format, and "+0100" is legal basic > format but illegal extended format, and mixing the 2 isn't legal. > Thanks for the reference. I've removed the mention of DateTime::ISO8601 from the RFC to make sure that the RFC text doesn't make any incorrect statements. Not going to include a deprecation proposal as part of this RFC though -- from past discussions, the topic was controversial, so I don't want to include it this late in the process. Regards, Nikita > On Tue, 15 Jun 2021 at 12:33, Christoph M. Becker > wrote: > > > On 23.03.2021 at 06:04, Stanislav Malyshev wrote: > > > > >> t fopen mode > > > > > > I'm afraid there's - despite the warning - a bunch of code for Windows > > > that relies on "t" and I don't think we should be breaking it. Is there > > > a good reason to drop this mode? > > > > I don't see much need for 't' mode nowadays. Even Notepad properly > > handles LF fine for some years now. It's not really bad, if it can be > > explicitely specified. However, deprecating 't' mode would pave the way > > to sometime change shell_exec() to no longer use 't' mode, what is a > > footgun when dealing with binary data. So when using the backtick > > operator on Windows, you always need to keep that in mind. From my > > experience, 't' mode causes more harm than good. > > > > And if there is really the need for LF conversion, that still can be > > done with an explicit filter. > > > > -- > > Christoph M. Becker > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: https://www.php.net/unsub.php > > > > >
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.1
i don't like this part of the RFC: > There's a number of bug reports related to this. From what I understand, the core problem here is not that the ISO8601 format is *wrong*, it's just one of multiple legal ISO-8601 formats. As DateTime formats always refer to a specific format, not a set of multiple possible ones, there doesn't seem to be anything actionable here. - this is wrong, DateTime::ISO8601 *is* illegal in ISO8601. quoting ISO8601:2004 section 4.3.3: > For reduced accuracy, decimal or expanded representations of date and time of day, any of the representations in 4.1.2 (calendar dates), 4.1.3 (ordinal dates) or 4.1.4 (week dates) followed immediately by the time designator [T] may be combined with any of the representations in 4.2.2.2 through 4.2.2.4 (local time), 4.2.4 (UTC of day) or 4.2.5.2 (local time and the difference from UTC) provided that (...skipped stuff...) d) the expression shall either be completely in basic format, in which case the minimum number of separators necessary for the required expression is used, or completely in extended format, in which case additional separators shall be used in accordance with 4.1 and 4.2. DateTime::ISO8601 does exactly what part "d" says isn't legal, 1970-01-01T01:00:00 is extended format, and +0100 is basic format, breaking the "the expression shall either be completely in basic format, in which case the minimum number of separators necessary for the required expression is used, or completely in extended format" -part. " 1970-01-01T01:00:00" is legal extended format but illegal basic format, and "+0100" is legal basic format but illegal extended format, and mixing the 2 isn't legal. On Tue, 15 Jun 2021 at 12:33, Christoph M. Becker wrote: > On 23.03.2021 at 06:04, Stanislav Malyshev wrote: > > >> t fopen mode > > > > I'm afraid there's - despite the warning - a bunch of code for Windows > > that relies on "t" and I don't think we should be breaking it. Is there > > a good reason to drop this mode? > > I don't see much need for 't' mode nowadays. Even Notepad properly > handles LF fine for some years now. It's not really bad, if it can be > explicitely specified. However, deprecating 't' mode would pave the way > to sometime change shell_exec() to no longer use 't' mode, what is a > footgun when dealing with binary data. So when using the backtick > operator on Windows, you always need to keep that in mind. From my > experience, 't' mode causes more harm than good. > > And if there is really the need for LF conversion, that still can be > done with an explicit filter. > > -- > Christoph M. Becker > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.1
On 23.03.2021 at 06:04, Stanislav Malyshev wrote: >> t fopen mode > > I'm afraid there's - despite the warning - a bunch of code for Windows > that relies on "t" and I don't think we should be breaking it. Is there > a good reason to drop this mode? I don't see much need for 't' mode nowadays. Even Notepad properly handles LF fine for some years now. It's not really bad, if it can be explicitely specified. However, deprecating 't' mode would pave the way to sometime change shell_exec() to no longer use 't' mode, what is a footgun when dealing with binary data. So when using the backtick operator on Windows, you always need to keep that in mind. From my experience, 't' mode causes more harm than good. And if there is really the need for LF conversion, that still can be done with an explicit filter. -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.1
On 22/03/2021 09:24, Nikita Popov wrote: It's time for another deprecation RFC: https://wiki.php.net/rfc/deprecations_php_8_1 I have added another proposal to this list: the 'ssl_method' option to the SoapClient constructor, which in practice only allows you to force use of SSLv3. A more flexible alternative is available via stream context options. https://wiki.php.net/rfc/deprecations_php_8_1#ssl_method_option_to_soapclient_constructor Note that both the SoapClient-specific and stream context versions of this are currently missing documentation, which I am working on improving. Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.1
Hi Nikita, I would like to propose a deprecation of FILTER_SANITIZE_STRING. This is a very dubious filter that has almost no use. It removes NUL bytes, encodes single and double quotes in HTML, and removes anything between < and optional >. It does not function the same as strip_tags() as pointed out in this comment https://www.php.net/manual/en/filter.filters.sanitize.php#118186 It is also one of the only two filters using FILTER_FLAG_NO_ENCODE_QUOTES flag. I believe this function is very misleading especially to new users who are looking for a default string filter. The real default one is called FILTER_UNSAFE_RAW which sounds like something one should not use. While in reality, it is FILTER_SANITIZE_STRING that can damage your data and should not be used. This also includes the deprecation of FILTER_SANITIZE_STRIPPED which is just its alias. Regards, Kamil
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.1
On Mon, Apr 12, 2021 at 3:15 PM Máté Kocsis wrote: > Hi Nikita and Stanislav, > > > > get_class(), get_parent_class() and get_called_class() without >> argument >> > >> > I'm not sure why. I mean if we want to make them return the same as >> > self::class etc. - up to the point of actually compiling them as such - >> > no problem, but I don't see why they need to be deprecated. And I >> > vaguely remember seeing get_class() at least a bunch of times in old >> > code, when ::class didn't even exist. I don't see a good reason why that >> > code should be broken. >> > >> >> I agree with you on this one. From my perspective, there should be some >> technical motivation for deprecations, and this one seems to be more about >> coding style -- it removes an old way to write something, which has been >> subsumed by a different construct in the meantime. I think Máté suggested >> this one, maybe he can provide additional reasoning. >> > > The technical motivation why I suggested this idea is because the optional > parameter of get_class() and get_parent_class() doesn't have a correct > default value > since https://wiki.php.net/rfc/get_class_disallow_null_parameter. So I > don't really mind > the coding style perspective, I'd only like to ensure that default value > handling is > right without reverting the relevant RFC. If you think it's too much of a > BC break for a > small gain, then I'm ok to remove this item from the list. > Just to get a rough idea on how common these are, on the top 2k composer packages: $ rg -t php "get_class\(\)" sources/ | wc -l 379 $ rg -t php "get_parent_class\(\)" sources/ | wc -l 174 $ rg -t php "get_called_class\(\)" sources/ | wc -l 218 For get_class() and get_parent_class() a large fraction of uses seem to be in generated code. get_parent_class() is almost always used to check if a parent class exists, not get what it actually is. So the replacement for that would be get_parent_class(self::class) rather than parent:class. Here's the grep output if you want to take a look: https://gist.github.com/nikic/12f963fbb4af9d0b2ef885a7417f6016 I don't have a strong opinion regarding the default value issue. It would be nicer if we did not have functions with argument count dependent behavior, but I also don't think it's a big deal in this case. These functions are still rather benign -- they don't perform crazy signature overloading like pg_query(), where it's impossible to express the signature in normal PHP code anymore. Overall I'm unsure the breakage is worthwhile here. Maybe someone else wants to chime in as well. Regards, Nikita
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.1
Hi Nikita and Stanislav, > > get_class(), get_parent_class() and get_called_class() without argument > > > > I'm not sure why. I mean if we want to make them return the same as > > self::class etc. - up to the point of actually compiling them as such - > > no problem, but I don't see why they need to be deprecated. And I > > vaguely remember seeing get_class() at least a bunch of times in old > > code, when ::class didn't even exist. I don't see a good reason why that > > code should be broken. > > > > I agree with you on this one. From my perspective, there should be some > technical motivation for deprecations, and this one seems to be more about > coding style -- it removes an old way to write something, which has been > subsumed by a different construct in the meantime. I think Máté suggested > this one, maybe he can provide additional reasoning. > The technical motivation why I suggested this idea is because the optional parameter of get_class() and get_parent_class() doesn't have a correct default value since https://wiki.php.net/rfc/get_class_disallow_null_parameter. So I don't really mind the coding style perspective, I'd only like to ensure that default value handling is right without reverting the relevant RFC. If you think it's too much of a BC break for a small gain, then I'm ok to remove this item from the list. Regards: Máté
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.1
On Tue, Mar 23, 2021 at 10:44 PM Kalle Sommer Nielsen wrote: > Hi > > Den man. 22. mar. 2021 kl. 11.25 skrev Nikita Popov >: > > > > Hi internals, > > > > It's time for another deprecation RFC: > > https://wiki.php.net/rfc/deprecations_php_8_1 > > I'd like to suggest adding `nl_langinfo()` to the list of > deprecations, it is a non-cross platform oddity that make less sense > with the current deprecations of functions like `strptime()` (also > non-cross platform) and `strftime()`. Personally I have seen more code > in the wild use array derefencing on `localeconv()` (which is cross > platform) over using `nl_langinfo()` for a single category. > I'm not really familiar with either of those (first time I hear about them, in fact), but it looks to me like localeconv() only covers part of the nl_langinfo() functionality. At a glance, at least the whole LC_TIME part isn't covered. I'm somewhat leery of deprecating functionality where we don't have any other way to access the same information. Regards, Nikita
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.1
On Tue, Mar 23, 2021 at 6:05 AM Stanislav Malyshev wrote: > Hi! > > > date_sunrise() and date_sunset() > > Do we have any information on usage? I am generally not a fan of > deprecating functions that work - even if they are odd and have quirky > APIs - but if the usage is essentially zero than it might be ok. > In my corpus of top 2k composer packages, the only real (not stub, metadata etc) reference to these functions is in the DateTime wrapper from Zend Framework 1: https://github.com/zendframework/zf1/blob/136735e776f520b081cd374012852cb88cef9a88/library/Zend/Date/DateObject.php#L913 That's not quite zero, but close... > key(), current(), next(), prev(), and reset() on objects > > I'd be happier if those worked with iterators. Except for prev() which I > don't think many people need. > Some thoughts on this topic: * These functions currently don't work with Iterators, so switching them to use the Iterator interface rather than object properties will be a BC break. Of course, we're looking at a BC break here in either case, but it's usually preferable to make something stop working entirely, rather than make it behave differently. * As these functions currently don't work on Iterators, the usual way to work with arbitrary iterables is to normalize everything to Iterator, that is convert arrays to Iterators via ArrayIterator. This works today and is essentially the only way to handle all iterables if you need something more than a simple foreach. Supporting Iterator in key() etc would add an alternative way to do this that works only in PHP 8.1. Why would I choose the new way over the old one? * There is a long-term goal to remove the "internal array pointer" concept from arrays. In PHP 5 this was used for all iteration, but as of PHP 8 the key() family of functions is the only part of PHP still using this concept. With this in mind, I'm generally inclined to encourage people to migrate away from using these functions, and make use of ArrayIterator instead, if they need to iterate arrays in complex ways. > mb_check_encoding() without argument > > No objection. > > > get_class(), get_parent_class() and get_called_class() without argument > > I'm not sure why. I mean if we want to make them return the same as > self::class etc. - up to the point of actually compiling them as such - > no problem, but I don't see why they need to be deprecated. And I > vaguely remember seeing get_class() at least a bunch of times in old > code, when ::class didn't even exist. I don't see a good reason why that > code should be broken. > I agree with you on this one. From my perspective, there should be some technical motivation for deprecations, and this one seems to be more about coding style -- it removes an old way to write something, which has been subsumed by a different construct in the meantime. I think Máté suggested this one, maybe he can provide additional reasoning. > > FILE_BINARY and FILE_TEXT constants > > No objection. > > > t fopen mode > > I'm afraid there's - despite the warning - a bunch of code for Windows > that relies on "t" and I don't think we should be breaking it. Is there > a good reason to drop this mode? > > > Passing bool for $amountOrUpOrDown argument of IntlCalendar::roll() > > Accessing static members on traits > > No objection. > > > strptime() > > strftime() and gmtstrftime() > > We have to remember many applications do not need to be portable, as > they will ever be only run on one setup - the one that the company > running it has. So non-portability itself should not be a fatal problem. > I am worried by musl thing mentioned - what exactly happens on musl, > they don't have strptime()? If it's just different outputs or some > options not supported, I think it's ok - warning in the docs should be > enough. > musl does have both strftime() and strptime(), but not with quite the same behavior as glibc. It's been a while, but for strftime() I believe the main issue was that %Z does not work. It's theoretically supported by musl, but the implementation is "maliciously compliant". At the time, I implemented some manual expansion for %Z to paper over the difference, but we ultimately decided that we shouldn't be trying to fix platform behavior in this way. Based on https://github.com/php/doc-en/commit/6936064e733f39045f471aad492abdeed7c4d2c6 the %P format also doesn't work. Based on my dataset of composer packages, there is not a single usage of strptime(), but strftime() does have around 150 references, including in Symfony and Drupal. I think my inclination here is to drop strftime() from the RFC and only keep strptime(). After all, strftime() is relatively portable if you avoid certain formats. strptime() is the one that's really non-portable, because it doesn't even have Windows support. > > mhash*() function family > > No objection. > > > ctype_*() function family accepts int parameters > > Here I think adding notice for int arguments would be appropriate, but
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.1
Hi Den man. 22. mar. 2021 kl. 11.25 skrev Nikita Popov : > > Hi internals, > > It's time for another deprecation RFC: > https://wiki.php.net/rfc/deprecations_php_8_1 I'd like to suggest adding `nl_langinfo()` to the list of deprecations, it is a non-cross platform oddity that make less sense with the current deprecations of functions like `strptime()` (also non-cross platform) and `strftime()`. Personally I have seen more code in the wild use array derefencing on `localeconv()` (which is cross platform) over using `nl_langinfo()` for a single category. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.1
Hi! > date_sunrise() and date_sunset() Do we have any information on usage? I am generally not a fan of deprecating functions that work - even if they are odd and have quirky APIs - but if the usage is essentially zero than it might be ok. > key(), current(), next(), prev(), and reset() on objects I'd be happier if those worked with iterators. Except for prev() which I don't think many people need. > mb_check_encoding() without argument No objection. > get_class(), get_parent_class() and get_called_class() without argument I'm not sure why. I mean if we want to make them return the same as self::class etc. - up to the point of actually compiling them as such - no problem, but I don't see why they need to be deprecated. And I vaguely remember seeing get_class() at least a bunch of times in old code, when ::class didn't even exist. I don't see a good reason why that code should be broken. > FILE_BINARY and FILE_TEXT constants No objection. > t fopen mode I'm afraid there's - despite the warning - a bunch of code for Windows that relies on "t" and I don't think we should be breaking it. Is there a good reason to drop this mode? > Passing bool for $amountOrUpOrDown argument of IntlCalendar::roll() > Accessing static members on traits No objection. > strptime() > strftime() and gmtstrftime() We have to remember many applications do not need to be portable, as they will ever be only run on one setup - the one that the company running it has. So non-portability itself should not be a fatal problem. I am worried by musl thing mentioned - what exactly happens on musl, they don't have strptime()? If it's just different outputs or some options not supported, I think it's ok - warning in the docs should be enough. > mhash*() function family No objection. > ctype_*() function family accepts int parameters Here I think adding notice for int arguments would be appropriate, but changing the behavior is not - we could cause some very nasty breaks in the code if we suddenly change such a basic thing. > Return by reference with void type > NIL constant defined by the IMAP extension No objection. > Calling overloaded pgsql functions without the connection argument I hate global state, but there are a lot of old quick-n-dirty scripts relying on stuff like that. Can we maybe check how common is usage of this pattern? > $num_points parameter of image(open|filled)polygon > mysqli::init() No objection. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.1
On 22/03/2021 17:27, Nikita Popov wrote: Sure. Rowan, if you would like to add these functions to this RFC, please feel free to just edit it directly. Otherwise, having a separate RFC just for them is also fine. Given the situation is complex, and at least somewhat controversial, I plan to write up a separate RFC, to make sure the pros and cons are fully understood. Any feedback on that topic, or suggestions for content of that RFC, please reply in the separate thread, to avoid de-railing this one. Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.1
On Mon, Mar 22, 2021 at 3:58 PM Ben Ramsey wrote: > > On Mar 22, 2021, at 04:24, Nikita Popov wrote: > > > > Hi internals, > > > > It's time for another deprecation RFC: > > https://wiki.php.net/rfc/deprecations_php_8_1 > > > > This is a collection of minor deprecations that various people have put > > together over the last ~2 years. This RFC was formerly targeted at PHP > 8.0, > > but was delayed to PHP 8.1 to reduce the amount of changes necessary for > > PHP 8.0 compatibility. > > > > As usual, each deprecation will be voted in isolation. > > > > As we're still early in the release cycle, it's still possible to add > > additional deprecation candidates, given reasoning for the deprecation, > as > > well as available alternatives. > > > > Of course, if there are compelling technical reasons why something should > > not be deprecated, we can move things into the "Removed from this > proposal" > > section, in which case it will serve as documentation why some > > functionality should not deprecated. > > > Given Rowan’s thread [1] on `utf8_encode()` and `utf8_decode()`, should we > consider adding these functions to this list or mentioning them in this > RFC as being handled separately? > Sure. Rowan, if you would like to add these functions to this RFC, please feel free to just edit it directly. Otherwise, having a separate RFC just for them is also fine. Regards, Nikita
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.1
Den 2021-03-22 kl. 15:58, skrev Ben Ramsey: On Mar 22, 2021, at 04:24, Nikita Popov wrote: Hi internals, It's time for another deprecation RFC: https://wiki.php.net/rfc/deprecations_php_8_1 This is a collection of minor deprecations that various people have put together over the last ~2 years. This RFC was formerly targeted at PHP 8.0, but was delayed to PHP 8.1 to reduce the amount of changes necessary for PHP 8.0 compatibility. As usual, each deprecation will be voted in isolation. As we're still early in the release cycle, it's still possible to add additional deprecation candidates, given reasoning for the deprecation, as well as available alternatives. Of course, if there are compelling technical reasons why something should not be deprecated, we can move things into the "Removed from this proposal" section, in which case it will serve as documentation why some functionality should not deprecated. Given Rowan’s thread [1] on `utf8_encode()` and `utf8_decode()`, should we consider adding these functions to this list or mentioning them in this RFC as being handled separately? Cheers, Ben [1] https://externals.io/message/113645 In order for that I think a clearer / better motivation is needed. For instance bug reports or community / documented feedback that these functions are giving rise to problems / are misused. Maybe also a checking how frequently thay are used in different Open source libraries. Found several occurences in the Revive ad server. r//Björn L -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.1
> On Mar 22, 2021, at 04:24, Nikita Popov wrote: > > Hi internals, > > It's time for another deprecation RFC: > https://wiki.php.net/rfc/deprecations_php_8_1 > > This is a collection of minor deprecations that various people have put > together over the last ~2 years. This RFC was formerly targeted at PHP 8.0, > but was delayed to PHP 8.1 to reduce the amount of changes necessary for > PHP 8.0 compatibility. > > As usual, each deprecation will be voted in isolation. > > As we're still early in the release cycle, it's still possible to add > additional deprecation candidates, given reasoning for the deprecation, as > well as available alternatives. > > Of course, if there are compelling technical reasons why something should > not be deprecated, we can move things into the "Removed from this proposal" > section, in which case it will serve as documentation why some > functionality should not deprecated. Given Rowan’s thread [1] on `utf8_encode()` and `utf8_decode()`, should we consider adding these functions to this list or mentioning them in this RFC as being handled separately? Cheers, Ben [1] https://externals.io/message/113645 signature.asc Description: Message signed with OpenPGP
