On 06.08.2024 at 21:07, Gina P. Banyard wrote:
> On Monday, 5 August 2024 at 23:55, Christoph M. Becker <cmbecke...@gmx.de>
> 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 = 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.
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 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.
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() that was
> being cast to a string and not the expected integer.
I have completely forgotten about this, and cannot really remember even now.
> 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 – 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
> 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.
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 – 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 = 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
