On 01.12.2024 at 21:32, Hans Henrik Bergan wrote:

> On Sun, Dec 1, 2024, 20:12 Christoph M. Becker <cmbecke...@gmx.de> wrote:
>
>> On 01.12.2024 at 19:26, mickmackusa wrote:
>>
>>> On Sun, Dec 1, 2024 at 10:01 PM Gina P. Banyard <intern...@gpb.moe>
>> wrote:
>>>
>>> Will it not be that these functions will be altered in the core to do
>> what
>>> the documentation says?
>>
>> If the docs are not correct, we cannot simply change the source to
>> conform for BC reasons.
>
> The same way we can't simply stop curl_close from writing to
> CURLOPT_COOKIEFILE for BC reasons?  (
> https://github.com/php/doc-en/issues/2239 )

My main point was (and is) that the docs are *unfortunately* not
authoritative; they still contain lots of out-dated and probably also
some wrong information.

The secondary point was (and is), that we *should* cater to BC.  That
is, unfortunately, not always possible; in this case it's about the
resource to object conversion, which when completely done, will get rid
of some nasty problems, which currently can barely worked-around.  And
when we change a resource type to a class, we know that some code does
is_resource() checks which are no longer valid, and that the close()
functions are no-ops.  There was some discussion about is_resource()
returning true for objects previously have been resources, but if I
remember correctly, that has been rejected.  And wrt the close()
functions there is barely anything we can do; well, we could put the
objects in some kind of unusable state, and actually close the
underlying "resource", but that seems even more hackish than having
is_resource() returning true for some objects.

So, in the end it's about weighing the pros and cons.  And there are
always different opinions regarding the decision.

Christoph

Reply via email to