Hi Kamil,

Thank you for your reply, it is pretty much appreciated!

I think one year of deprecation is not enough. I believe the functions
> that get replacements should be deprecated immediately in PHP 8.3 to
> give people two years of deprecation notice. It doesn't make sense to
> me to add a replacement but not deprecate the old variant.
>

Yes, this upgrade path also makes sense to me, and I'm happy to go with
it if others don't disagree! Probably my approach would be advantageous
if we were earlier in the 8.x lifecycle.


> `($rm = new ReflectionMethod(explode(“::”, $string));) ` I think you
> forgot a splat operator here.
>

Fixed!


> ReflectionProperty::setValue could have an alternative called
> ReflectionProperty::setStaticValue. Then there would be no need for
> the unused parameter anymore.
>

Originally, my proposal had this method, but at last I removed it based on
Nicolas' suggestions. I think both ways make sense, a single setValue() is
probably much easier from the migration point of view, since the suggested
alternative is already there in older PHP versions. And it doesn't mean
we cannot have a ReflectionProperty::setStaticValue() later on. :)


> The overload of array_keys should be replaced with a new function
> array_search_all. This overload is little known and very confusing.
>

Thanks for pointing this out, I'll look into this soon!


>
> The overload of ldap_exop should just be deprecated. An alternative
> already exists and is the preferred way.
>

I've just included ldap_exop() in the RFC, albeit slightly differently to
your
suggestion: since this function performs the extended operation
synchronously
or asynchronously based on whether the $response_data parameter is provided,
we cannot simply deprecate and remove the latter one, because as far as I
can understand, synchronous communication is also a valid use-case. So I
went
with adding an ldap_exop_sync() function.


> I wasn't aware that pg_execute has an overload apart from the default
> connection one. Could you explain what that overload is?
>

You are right, as it turned out for me, there is no other overload indeed,
so I removed
it from the RFC.


> stream_context_set_option should get alternative
> stream_context_set_option_array.
>

Thanks for the suggestion! I incorporated this suggestion into the RFC
(using
the stream_context_set_options name though).

What is the last item in Future scope supposed to be, because I think
> ReflectionProperty is a typo.
>

Right, it's now removed.


> Why is implode() not mentioned in this RFC?
>

Because it's not overloaded anymore. :) Even though the manual lists
multiple signatures
for it, its exact signature is the following:

function implode(string|array $separator, ?array $array = null): string {}

I'm not sure how much people would miss the possibility to use implode with
a
single argument ("implode($array)"), but if that's the case, we can add it
to the
usual PHP 8.3 or PHP 8.4 Deprecations RFC. I wouldn't like to add it to
mine,
because it's already way too long.

Regards:
Máté

Reply via email to