Hi internals,
Based on the feedback I had from my proposal for function arguments in
errors last week, I'd like to introduce an RFC for it. Please let me
know what you think and please raise any possible issues.
https://wiki.php.net/rfc/display_error_function_args
Regards,
Calvin
Hi internals,
Based on the feedback I had from my proposal for function arguments in
errors last week, I'd like to introduce an RFC for it. Please let me
know what you think and please raise any possible issues.https://wiki.php.net/rfc/display_error_function_args
Regards,
Calvin
I'm looking forward to this RFC, as normalizing the behaviour of diagnostics by removing the various docref functions is something I proposed back in 2019. [1]
And I do think that we should remove the parameter versions of the docref functions as the behaviour of them if this is accepted seems hard to determine.
Best regards,
Gina P. Banyard
Hi
Based on the feedback I had from my proposal for function arguments in
errors last week, I'd like to introduce an RFC for it. Please let me
know what you think and please raise any possible issues.
Thank you for the RFC. I have the following comments:
I believe there is almost never “No Impact” to the ecosystem. In fact
the RFC partly acknowledges it in the “Backward Incompatible Changes”
section. Even if the corresponding sub-vote to default to 1 doesn't
pass, code needs to be prepared for someone to set it to 1 themselves.
This includes off-the-shelf software (such as WordPress, or Drupal, or
whatever).
I have the following two suggestions (that follow pretty naturally, but
are nevertheless an impact that should be spelled out):
a) Custom error handlers (set_error_handlers()) need to be prepared for
the error message format to change. Even though we don't make any
guarantees about error messages themselves, the existing format with
“function name first” is reasonably structured for automated parsing
(e.g. using a regular expression). This also includes error tracking
tools that try to group error messages by function or similar.
b) System administrators have one more INI setting to deal with and need
to make a decision. Previous versions of the RFC template had an
explicit “INI setting” section, but given it's so rare we add new INI
settings these days, it has been removed from the template. For the few
that still add one, properly discussing the consequences still is valuable.
As for the naming of the bikeshed, I suggest error_ignore_args for
consistency with zend.exception_ignore_args.
For the voting options: You need to define a tie-breaker for the
secondary votes.
Best regards
Tim Düsterhus