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
