On 12/09/2019 16:44, Zeev Suraski wrote:
Similarly - adding typed variables - is certainly a future option. Changing
PHP to require typed variables (without opting in) - is well outside of the
internals@ mandate.
For areas like that - our options are either doing nothing, or providing
opt-in mechanisms to cater to stricter-loving audiences. I'm all for the
2nd option, but there is no 3rd.
While I am not sure your tone will be well received by your target
audience, I just wanted to say I tend to agree.
Breaking BC here does not seem to bring much. If there are cases where
enforcing strictness might allow better JIT for example, then I could
see the case being made. But simply turning working code into fatally
failing code isn't progress.
I know I have a bunch of old stuff running which tends to litter the
error logs with notices, and I don't have time to go fix them so I
ignore because it's fine and it works.
For new projects, what I do, and what I am pretty sure 99% of the
"strict camp" does is essentially boiling down to:
set_error_handler(function () { throw new \RuntimeException(); });
That's our global strictness flag right there. It's been available for
ages. I don't see why we need to take something away from others to make
such an easy workaround a little less needed. Especially as I don't
imagine we will drop the error handlers. I sure will keep mine around to
keep failing warnings etc as hard fatals.
So what do we gain exactly?
Best,
Jordi
--
Jordi Boggiano
@seldaek - https://seld.be
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
