Hi
On 10/28/22 18:25, Jeffrey Dafoe wrote:
Informally, doesn't this mean that voters wanted a and c in PHP9?
Not necessarily. It might be that a voter does not like the Exception
wrapping at all (thus declining the proposal), but *if* it happens to be
accepted then also increasing everything to Exception would be be an
obvious follow-up to them (thus declining the other proposal).
Also I've taken care to explicitly spell out the "terms of vote" before
starting the voting to make sure voters are able to make an informed
decision and making assumptions violates that informed decision.
Does this vote mean it's dead for 9, or just that it needs a vote at some point
in the future with the choices grouped different?
I believe
https://wiki.php.net/rfc/voting#resurrecting_rejected_proposals answers
your question here.
My understanding is that it may be reproposed after April 28, 2023, or
earlier when substantial changes are made. Whether the change of target
versions or voting dependencies constitute such a substantial change, I
don't feel qualified to answer.
In any case I do not plan to repropose the RFC myself, for two reasons
that both relate to the fact that I've written the RFC and developed the
PoC patch in my free time (a co-worker proof-read the initial version of
the RFC itself on company time, though):
a) The discussion phase and voting phase were both pretty exhausting to
me mentally. One of the reasons is that the folks following the RFC on
Twitter were not pointed to the related discussion thread, thus were
missing out on important information and thus asked questions that were
already answered without them knowing about it and needed to be answered
again.
b) As a "personal time" contributor I personally find it demotivating if
I need to wait until the next major (possibly multiple years) before I
am able to use and rely on what I proposed myself.
I've written the RFC such that I am happy with what I proposed and such
that I feel that I spent my free time well.
Even if the proposal was partly rejected, it ultimately still benefitted
me, as I've learned something: I've learned that how I handled
unserialize() failures in code I've written is unsafe and broken. I will
improve my own code based on that and I strongly recommend everyone else
who followed along the discussion to also do that:
The only safe error handling is (1) using a throwing error handler, and
then (2) using catch(Throwable) without relying on a specific type of
Exception.
------------
If someone wants to pick this up, they are free re-use (parts of) the
words I've written for the RFC. The 'Increase the error reporting
severity in the unserialize() parser' section will likely need to be
rewritten, as the proposal (b) "unify Notice to Warning" passed. A short
private heads-up is appreciated, but not required. If assistance with
the C implementation is required, I might be able to help out as well.
Best regards
Tim Düsterhus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
