Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124814
Date: Tue, 06 Aug 2024 19:07:34 +0000
To: "Christoph M. Becker" <cmbecker69@gmx.de>
Cc: =?utf-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>, Derick Rethans <derick@php.net>, PHP internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] [VOTE] Transform exit() from a languageconstructinto a standard function
Message-ID: <E1Gh0wZryyfglasc0UfBb9BeTLVcnI7lpHjWx3LOopxHxuSlSo2N9v2ckjYefPAxLGlE2cLiJ8xIip_oFPskAM1wFT8Fw_FYInGeEF0vsAQ=@gpb.moe>
In-Reply-To: <b5058a7e-b5bc-4fae-b4a2-ef7ead311c39@gmx.de>
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>
Feedback-ID: 96993444:user:proton
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: internals@gpb.moe ("Gina P. Banyard")

On Monday, 5 August 2024 at 23:55, Christoph M. Becker <cmbecker69@gmx.de> =
wrote:

> On 05.08.2024 at 21:37, Gina P. Banyard wrote:
>=20
> > This sounds like a uopz extension issue that is easily fixed.
>=20
>=20
> 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 eve=
n land in the first place?
We do countless engine breaking changes without RFCs and without notices to=
 extension maintainers other than UPGRADING.INTERNALS.

May I remind everyone that PHP 8.1 had a huge breaking change for extension=
s in utterly rewriting the stream API:

> Zend Stream API has been changed to use "zend_string*" instead of "char*"=
 [1]

Extension developers have somehow coped with it and/or just suffered in sil=
ence.
We didn't provide ANY help for extension developers to make the move easier=
.
It is getting frustrating that on one hand we treat extension developers li=
ke they are idiots incapable of updating their extension for minor changes =
in engine APIs and behaviour (or even just including the proper headers cir=
cling, back to *that* whole drama)
While at the same time kicking them in the face with massive, and potential=
ly clunky #ifdef checks, code churn for major engine API changes that get Z=
ERO discussion and expect them to be competent at their job.

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 pr=
oject, clearly don't seem to care in our actual action?
Because I find it a tad strange that every time I point the above stream AP=
I design change, the only thing I hear back is crickets.

>=20
> > I am not sure why we should bend over backwards for extensions that all=
ow to break usual userland semantics while preventing userland behaviour to=
 be better.
>=20
>=20
> We shouldn't do one or the other without having weighted the pros and
> cons. So what are the pros regarding improved userland behavior:
>=20
> * we can use named arguments
>=20
> So we can now write `exit(status =3D 1)` or `exit(status =3D "some error =
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.

>=20
> * pass to functions as callable
>=20
> That might be a nice feature, but at least I have never seen the need to
> 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 not =
a justification against this RFC.
=20
> * does not respect strict_types and does not follow usual type juggling
> semantics
>=20
> 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 whi=
le 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() that w=
as being cast to a string and not the expected integer.

So I would argue you have stumbled upon this.


>=20
> Perhaps I've missed some pros, but it seems these have been the ones the
> RFC explicitly mentions.
>=20
> So, what are the cons:
>=20
> * removing the ZEND_EXIT opcode
>=20
> That immediately breaks any extension using it. A quick Github search
> lists 3.1 k occurrences[1].

Please see point about the stream layer API change.

>=20
> * making exit a "proper" function
>=20
> 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):
>=20
> | exit is a language construct and it can be called without
> | parentheses if no status is passed.
>=20
> Weighting the pros and cons is left as an exercise to the reader.
>=20
> [1] https://github.com/search?q=3DZEND_EXIT&type=3Dcode

Since when has the documentation been the normative aspect of PHP?
We routinely fix the documentation to explain the Zend engine's true behavi=
our, 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.


Best regards,

Gina P. Banyard

[1] https://github.com/php/php-src/blob/PHP-8.1/UPGRADING.INTERNALS#L36