Re: Re: Inaccurate documentation on return values from native functions

On 01.12.2024 at 21:32, Hans Henrik Bergan wrote: > On Sun, Dec 1, 2024, 20:12 Christoph M. Becker <cmbecker69@gmx.de> wrote: > >> On 01.12.2024 at 19:26, mickmackusa wrote: >> >>> On Sun, Dec 1, 2024 at 10:01 PM Gina P. Banyard <internals@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