Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124818
Message-ID: <ac1935b1-2f63-4aef-89af-7e6b4cbbf5ff@gmx.de>
Date: Wed, 7 Aug 2024 02:02:34 +0200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] [VOTE] Transform exit() from a
 languageconstructinto a standard function
Content-Language: de-DE
To: "Gina P. Banyard" <internals@gpb.moe>
Cc: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>,
 Derick Rethans <derick@php.net>, PHP internals <internals@lists.php.net>
References: <WAN6ETlWt7JfcVoyeYfY_F_eLE6WzQa87F7yi8SHISmyktMYx7YcA6oG5dis3gFeI36VBjSfjGw4AT6psFFDXEUNRrvKRRn4LxfdCxFBccw=@gpb.moe>
 <15bb76a0-cbd7-4145-b429-76d424755106@gmx.de>
 <1a8650d2-7eb5-d645-8132-e5522ad24637@php.net>
 <06ba1d82-6387-46ac-8be3-1d3472993e1a@gmx.de>
 <a2cf19e2-4c42-42a1-b060-205b782252c8@bastelstu.be>
 <e7baad83-9604-4693-aa51-b1148722f750@gmx.de>
 <LrQv9MxcBzy8z0lmKDxDhL-13Ull8cRO5GHlJR9DNMcagZB6XllEot2MdMnC-K31pTCRyfkgLtksJl_UyLKktUmOXgK5VdpPbs2ES3U7PmI=@gpb.moe>
 <b5058a7e-b5bc-4fae-b4a2-ef7ead311c39@gmx.de>
 <E1Gh0wZryyfglasc0UfBb9BeTLVcnI7lpHjWx3LOopxHxuSlSo2N9v2ckjYefPAxLGlE2cLiJ8xIip_oFPskAM1wFT8Fw_FYInGeEF0vsAQ=@gpb.moe>
In-Reply-To: <E1Gh0wZryyfglasc0UfBb9BeTLVcnI7lpHjWx3LOopxHxuSlSo2N9v2ckjYefPAxLGlE2cLiJ8xIip_oFPskAM1wFT8Fw_FYInGeEF0vsAQ=@gpb.moe>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
UI-OutboundReport: notjunk:1;M01:P0:5RrIMyu4YHE=;uobzyvXIGM0F/20Ro2tfaFPRb/w
 V3lA5OJfqh9TJfdTJ3ASYMOGUpO5VDdPm2xX0G82RNT/1CxgR2PBNaZwl/JHxTYLg2G4SH58J
 a9UqCsNl1CuUcqZpXwFwS2F5WJC6ARzllZ+uQ76D/EQ2p3LnvloqSNKbYsOxB4UKhpjRacIqI
 8p4BnRhQVhtjhrtZrqXNR2o7dVjXFrFi639cqTtJ3LWyiq4uHWTDnIVJWKqmz1FMyalTka15i
 2jHi/abAq3QprXez5m3BptfSW3mUh1qZRv/2W9thmkTyzKhbhviC1p4srrivNRq15Ph89SWeu
 hw9GdjRotGnJ07c3sXfKd0GdIfXxtCJmh8UlyK0T2C5iAEBssxr5Fy35axzixndx6fRUUdZXX
 F0VJUiGpduM8aYzsRUYAy2L9wxLrW98QtZAM8qJqIYwXiJaQ7Kk2sLMhYMgFdcJo2csbGiHuh
 z8ifLuoK4u0MkxDpepXfODm/gEzMd4OFAV79oPNga8lwYA8J33nVKLMZc+B+J9T5vhzMSMgAf
 RXkTMGrrPU+vF1XlZAAl/QYiAh9QE58yRW+yHsry4uqWRLt0G7g/na5i/UHlMvJZVrejxwkIR
 rjKgMaxrH0XOlQa9cKxQO11p5l4oSrhq6exycd/JHQQj5pSNw5xNT1HoJGfCW0rJM7HXhgMq9
 Zvz+5rR8T5lXa7D2oDEPJz73bXgMF3aWSg04InuScV25fbO71lY1vLAytQ9guxRPyenKIUvNb
 xyT2TVsLipS39ggNqfuXW9YIlHDR+ZZOfxnsgDW6EOA8qdrzU223vxf7Dje6a1UKuFLexvIBJ
 a87s/n13iMDiVzOljdzhvykQ==
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 06.08.2024 at 21:07, Gina P. Banyard wrote:

> On Monday, 5 August 2024 at 23:55, Christoph M. Becker <cmbecker69@gmx.d=
e> wrote:
>
>> Most likely, yes, although still somebody has to provide a fix, and
>> someone has to do a new release.
>
> Why should I investigate time to fix extensions when this RFC might not =
even land in the first place?

I do not expect anybody who makes approved changes to the APIs to
provide fixes for any of the affected external extensions.  It's great
if they help when asked, and it's okay if they don't.

I merely noted that someone has to make these changes to keep these
extensions up-to-date for new PHP releases.  And sometimes real life
interferes for the maintainers, so they don't have time (due to other
interests, health issues, a new job, family, etc.)  And even if others
would like to help out, sometimes they can't[1].

> We do countless engine breaking changes without RFCs and without notices=
 to extension maintainers other than UPGRADING.INTERNALS.

That is exactly my point: we should weight the pros and cons of any API
change carefully.  How many extensions may be affected, how hard would
it be to update these extensions, how ugly would the resulting code be
due to PHP_VERSION_ID checks, etc.  And on the other hand, what would be
the benefits for the whole ecosystem (php-src, extensions, userland
developers).

> Could we maybe start respecting the intelligence of extension developers=
?
> And if not, can we stop pretending that we care about them when we, as a=
 project, clearly don't seem to care in our actual action?

We should not fall into the trap of thinking: we did more seriously
breaking changes in the past, so we don't need to care anymore.  After
all, we cannot change what had happened, but we may be able to improve.

>> So we can now write `exit(status =3D 1)` or `exit(status =3D "some erro=
r message`). I don't see any improvement using named arguments for a
>> single argument function (maybe unless it is a boolean argument). And
>> for a string argument, I don't think that `status` is a sensible
>> parameter name here.
>
> Please propose a better name then.

That's the crux with some of the union types for legacy functions: there
are no suitable names.  setcookie() has an $expires_or_options
parameter, so we might choose $status_or_message here, and although that
seems to be more correct, it would be ridiculous to use this as named
argument.

(For the record: I've got the syntax wrong, because I don't use named
arguments, since these are fixing the symptoms, not the desease, which
is a bad API.)

>> That might be a nice feature, but at least I have never seen the need t=
o
>> pass `exit` as callable. And it wouldn't be hard to define a wrapper
>> function (e.g. `my_exit()`) if someone really needs to pass it as a
>> callable.
>
> The fact that one might need to do this workaround is bad already, and n=
ot a justification against this RFC.

The fact that one might need to pass `exit` implies that they are using
some test helper extension (e.g. uopz) to stub/mock it, or that they
should consider to consult a therapist. ;)

>> That might be an issue (although I've never stumbled upon that), but
>> it seems to me that this could even be handled in the ZEND_EXIT handler=
.
>
> Now see this is strange to me, as I clearly remember hitting this issue =
while working on a QA scrip for the PHP documentation,
> was not understanding why CI was failing with no output,
> until you realised that the issue was me passing a boolean to exit() tha=
t was being cast to a string and not the expected integer.

I have completely forgotten about this, and cannot really remember even no=
w.

> So I would argue you have stumbled upon this.

I stand corrected.  However, that doesn't invalidate my argument that at
least some sanity could be introduced in the ZEND_EXIT handler instead
of pursuing the RFC at hand.

>> It still can be called without parentheses, so I don't regard it as a
>> proper function. It might even be confusing to readers ("oh, now I
>> can call a function without arguments by omitting the parentheses =E2=
=80=93 but
>> why doesn't it work for other functions?"). And the PHP manual even
>> states (emphasis mine):
>>
>> | exit is a language construct and it can be called without
>> | parentheses if no status is passed.
>
> Since when has the documentation been the normative aspect of PHP?
> We routinely fix the documentation to explain the Zend engine's true beh=
aviour, even if it doesn't make any sense.
>
> This sentence is true as of now, and may be changed if this RFC passes.
> Using current wording on the documentation is.... a strange argument to =
me.

Fair enough.  So just ignore that last part, but what about:

It still can be called without parentheses, so I don't regard it as a
proper function. It might even be confusing to readers ("oh, now I
can call a function without arguments by omitting the parentheses =E2=80=
=93 but
why doesn't it work for other functions?").

Anyhow, perhaps an alternative to the proposal at hand would be to
implement the following proper function in the core:

function quit(int $status =3D 0) {
    exit($status);
}

Users who wish to have something like die("message"), could use it, or

echo "message";
quit()

Or perhaps that could be a set of quit functions; the main point is not
to *change* anything in the core (for now), but still allowing users to
*opt into* some cleaner functionality.

[1] <https://github.com/krakjoe/pcov/pull/103#issuecomment-2269612656>

Cheers,
Christoph