On Monday, 5 August 2024 at 23:55, Christoph M. Becker <cmbecke...@gmx.de>
wrote:
> On 05.08.2024 at 21:37, Gina P. Banyard wrote:
>
> > This sounds like a uopz extension issue that is easily fixed.
>
>
> 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?
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 extensions 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 silence.
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 like
they are idiots incapable of updating their extension for minor changes in
engine APIs and behaviour (or even just including the proper headers circling,
back to *that* whole drama)
While at the same time kicking them in the face with massive, and potentially
clunky #ifdef checks, code churn for major engine API changes that get ZERO
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
project, 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 API
design change, the only thing I hear back is crickets.
>
> > I am not sure why we should bend over backwards for extensions that allow
> > to break usual userland semantics while preventing userland behaviour to be
> > better.
>
>
> We shouldn't do one or the other without having weighted the pros and
> cons. So what are the pros regarding improved userland behavior:
>
> * we can use named arguments
>
> So we can now write `exit(status = 1)` or `exit(status = "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.
>
> * pass to functions as callable
>
> 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.
> * does not respect strict_types and does not follow usual type juggling
> semantics
>
> 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() that was
being cast to a string and not the expected integer.
So I would argue you have stumbled upon this.
>
> Perhaps I've missed some pros, but it seems these have been the ones the
> RFC explicitly mentions.
>
> So, what are the cons:
>
> * removing the ZEND_EXIT opcode
>
> 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.
>
> * making exit a "proper" function
>
> 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 – 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.
>
> Weighting the pros and cons is left as an exercise to the reader.
>
> [1] https://github.com/search?q=ZEND_EXIT&type=code
Since when has the documentation been the normative aspect of PHP?
We routinely fix the documentation to explain the Zend engine's true behaviour,
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
