Scott Arciszewski wrote on 27/07/2015 07:57:
My only concern is that, we have a fixed timetable for the 7.0.0
release. It's certainly a good idea to develop a cogent strategy
before moving forward, but I worry that bikeshedding will get involved
and we won't make the deadline.
I propose that, if a better strategy cannot be presented in time for
RC1, consistency should take a back seat to security. Fail hard, throw
an Error, deal with the details later.
I think taking on board Anatol's concerns about proper planning and
consistency, and yours about short timescales, the reasonable solution
is to create as small a possibility for future BC as possible, while
maintaining the "fail hard" policy.
My suggestion would therefore be to raise an E_ERROR for this case in
7.0. Unlike an E_RECOVERABLE_ERROR or any kind of Throwable, there is no
way that code can be written to explicitly handle that case, it will
simply halt execution. As such, there are no limits to what we can
introduce later, other than that unmodified code should continue to fail
hard.
This buys us time to put together a cogent policy for what if any
built-in functions can make use of Throwables in the 7.x release series,
with a likely result of throwing some class of Error for this function
in 7.1.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
