# [RFC] Deprecations for PHP 8.1 - Thread: https://externals.io/message/113657 - Original archive: https://news-web.php.net/php.internals/113657 - Started by Nikita Popov on 2021-03-22T09:24:51+00:00 - Messages: 36 - RFC: Deprecations for PHP 8.1 (Implemented (PHP 8.1)) — https://externals.io/rfc/deprecations_php_8_1.md - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/113657.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #113657 — Nikita Popov — 2021-03-22T09:24:51+00:00 URL: https://externals.io/message/113657#113657 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 --- ## #113672 — Ben Ramsey — 2021-03-22T14:58:16+00:00 URL: https://externals.io/message/113657#113672 · In reply to: #113657 > > > 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 --- ## #113688 — bjorn.x.larsson@telia.com — 2021-03-22T17:16:56+00:00 URL: https://externals.io/message/113657#113688 · In reply to: #113672 Den 2021-03-22 kl. 15:58, skrev Ben Ramsey: > > […] > > > 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 --- ## #113693 — Nikita Popov — 2021-03-22T17:27:42+00:00 URL: https://externals.io/message/113657#113693 · In reply to: #113672 > > […] > 8.0, > > […] > as > > […] > proposal" > > […] > > > 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 --- ## #113694 — Rowan Tommins — 2021-03-22T17:35:56+00:00 URL: https://externals.io/message/113657#113694 · In reply to: #113693 > > 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] --- ## #113710 — Stanislav Malyshev — 2021-03-23T05:04:37+00:00 URL: https://externals.io/message/113657#113710 · In reply to: #113657 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 smalyshev@gmail.com --- ## #113733 — Kalle Sommer Nielsen — 2021-03-23T21:44:15+00:00 URL: https://externals.io/message/113657#113733 · In reply to: #113657 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 kalle@php.net --- ## #113800 — Christoph M. Becker — 2021-03-26T14:41:53+00:00 URL: https://externals.io/message/113657#113800 · In reply to: #113657 > It's time for another deprecation RFC: > https://wiki.php.net/rfc/deprecations_php_8_1 > > 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. I'd like to propose the deprecation of odbc_result_all()[1]. My main motivation for getting rid of this function is to reduce unnecessary complexity in the ODBC extension. I doubt that this function is used (often) in production code, and even for quick experiments/tests it is unlikely to be helpful. For those needing it, it shouldn't be hard to implement it in PHP. [1] -- Christoph M. Becker --- ## #114033 — Nikita Popov — 2021-04-12T12:55:47+00:00 URL: https://externals.io/message/113657#114033 · In reply to: #113710 On Tue, Mar 23, 2021 at 6:05 AM Stanislav Malyshev wrote: > Hi! > > > […] > > 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. > > > […] > > 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. > > […] > > No objection. > > > […] > > 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? > > > […] > > No objection. > > > […] > > 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. > > […] > > No objection. > > > […] > > 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. > Hm, yes, I can understand your concern here. I think it's worth pointing out though that we have already gone through this process for quite a few other functions already. E.g. passing a codepoint to `strpos()` was deprecated in PHP 7.3 and then the behavior changed in PHP 8.0 to always treat the input as a string. The current proposal is to do the same thing here. > > […] > > No objection. > > > […] > > 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? > I checked my composer dataset for uses of pg_query() and pg_prepare() without connection, and the only hits were the function wrappers in the safe library, which just mirror whatever PHP does ( https://github.com/thecodingmachine/safe/blob/4cc05ada622d30746f573695f748d44585981efa/generated/pgsql.php#L1446). Of course, this is a case where it's more likely that such usage is found in applications rather than libraries (as libraries cannot assume no other connections exist), so this result should be taken with a grain of salt. Nikita --- ## #114034 — Nikita Popov — 2021-04-12T12:57:55+00:00 URL: https://externals.io/message/113657#114034 · In reply to: #113657 > Hi internals, > > It's time for another deprecation RFC: > https://wiki.php.net/rfc/deprecations_php_8_1 > I have updated the RFC to include two more items: * The filter.default ini setting, aka "magic quotes but even worse". * auto_detect_line_endings, aka "support for 20 year old classic macs" Nikita --- ## #114035 — Nikita Popov — 2021-04-12T13:06:22+00:00 URL: https://externals.io/message/113657#114035 · In reply to: #113733 > Hi > > Den man. 22. mar. 2021 kl. 11.25 skrev Nikita Popov > […] > > 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 --- ## #114036 — Nikita Popov — 2021-04-12T13:11:51+00:00 URL: https://externals.io/message/113657#114036 · In reply to: #113800 On Fri, Mar 26, 2021 at 3:41 PM Christoph M. Becker wrote: > > > > […] > as > > […] > > I'd like to propose the deprecation of odbc_result_all()[1]. My main > motivation for getting rid of this function is to reduce unnecessary > complexity in the ODBC extension. I doubt that this function is used > (often) in production code, and even for quick experiments/tests it is > unlikely to be helpful. For those needing it, it shouldn't be hard to > implement it in PHP. > > [1] > I'm on board with deprecating odbc_result_all(). This is pretty much the archetype of old school PHP -- make a query and dump the result right into an HTML table... Escaping? Who needs that! Nikita --- ## #114037 — kocsismate90@gmail.com — 2021-04-12T13:15:02+00:00 URL: https://externals.io/message/113657#114037 · In reply to: #114033 Hi Nikita and Stanislav, > > […] > > 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é --- ## #114038 — Nikita Popov — 2021-04-12T13:33:23+00:00 URL: https://externals.io/message/113657#114038 · In reply to: #114037 > Hi Nikita and Stanislav, > > > […] > > 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 --- ## #114079 — Kamil Tekiela — 2021-04-19T21:31:03+00:00 URL: https://externals.io/message/113657#114079 · In reply to: #114038 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 --- ## #114133 — Rowan Tommins — 2021-04-24T17:37:46+00:00 URL: https://externals.io/message/113657#114133 · In reply to: #113657 > 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] --- ## #114881 — Christoph M. Becker — 2021-06-15T10:33:30+00:00 URL: https://externals.io/message/113657#114881 · In reply to: #113710 > > […] > > 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 --- ## #114883 — Hans Henrik Bergan — 2021-06-15T10:47:56+00:00 URL: https://externals.io/message/113657#114883 · In reply to: #114881 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. > > > > […] > > 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 > > -- > > To unsubscribe, visit: https://www.php.net/unsub.php --- ## #114884 — Nikita Popov — 2021-06-15T10:53:47+00:00 URL: https://externals.io/message/113657#114884 · In reply to: #113657 > 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. > 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. Regards, Nikita --- ## #114885 — Nikita Popov — 2021-06-15T12:23:50+00:00 URL: https://externals.io/message/113657#114885 · In reply to: #114883 On Tue, Jun 15, 2021 at 12:48 PM Hans Henrik Bergan wrote: > i don't like this part of the RFC: > > > […] > 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: > > > […] > 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: > > > […] --- ## #114886 — Hans Henrik Bergan — 2021-06-15T13:54:09+00:00 URL: https://externals.io/message/113657#114886 · In reply to: #114885 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, Jun 15, 2021 at 12:48 PM Hans Henrik Bergan > wrote: > > > […] > > 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 > > > > […] --- ## #114889 — come.chilliet@fusiondirectory.org — 2021-06-15T14:46:34+00:00 URL: https://externals.io/message/113657#114889 · In reply to: #114884 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 --- ## #114901 — Mike Schinkel — 2021-06-16T03:59:08+00:00 URL: https://externals.io/message/113657#114901 · In reply to: #114884 > > > 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 --- ## #114904 — Larry Garfield — 2021-06-16T11:38:39+00:00 URL: https://externals.io/message/113657#114904 · In reply to: #114901 > > […] > > 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 --- ## #114965 — Rowan Tommins — 2021-06-18T18:33:09+00:00 URL: https://externals.io/message/113657#114965 · In reply to: #114884 > 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] --- Next page: https://externals.io/message/113657.md?page=2