Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113710
To: internals@lists.php.net
References: <CAF+90c9crhPpSMcTx-ozGo0LGjNuBU43e8fiK_=PJMU6iTHNmw@mail.gmail.com>
Message-ID: <28be190c-21ea-b796-cec7-b8db21d14eca@gmail.com>
Date: Mon, 22 Mar 2021 22:04:37 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
 Gecko/20100101 Thunderbird/78.8.1
MIME-Version: 1.0
In-Reply-To: <CAF+90c9crhPpSMcTx-ozGo0LGjNuBU43e8fiK_=PJMU6iTHNmw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 8.1
From: smalyshev@gmail.com (Stanislav Malyshev)

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