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
