[RFC] Deprecations for PHP 8.1 View as Markdown

Den 2021-03-22 kl. 15:58, skrev Ben Ramsey:

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

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

On Tue, Mar 23, 2021 at 6:05 AM Stanislav Malyshev smalyshev@gmail.com
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
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.

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?

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

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

Hi

Den man. 22. mar. 2021 kl. 11.25 skrev Nikita Popov <nikita.ppv@gmail.com

:

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

On Fri, Mar 26, 2021 at 3:41 PM Christoph M. Becker cmbecker69@gmx.de
wrote:

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] https://www.php.net/manual/en/function.odbc-result-all.php

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

On Sat, Apr 24, 2021 at 7:38 PM Rowan Tommins rowan.collins@gmail.com
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

Hello,

Le Tue, 15 Jun 2021 12:53:47 +0200,
Nikita Popov nikita.ppv@gmail.com 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

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

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]

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

--

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.