On 10/22/2013 06:20 PM, Adam Harvey wrote:
On 22 October 2013 02:08, Derick Rethans <der...@php.net> wrote:
I'm pretty convinced that expectations *without* exceptions are a good
idea, as using assert (which is really eval) is a nasty thing that
should be replaced, but IMO exception throwing should not be part of
this feature.
I agree that something to replace the eval-based assert() would be
good. What if the new syntax simply respected assert_options(), and
assert_options() was extended to support an explicit ASSERT_EXCEPTION
control option (that presumably took an exception class name as its
option value)? That seems like it would provide the exception based
possibilities that some posters want while maintaining the same
assertion behaviour that users are already used to by default.
Adam, who apologises if this has been suggested before — this was a
long set of threads and I've been busy.
I'm a bit perplexed at the need to retain any compatibility with what is
a poor implementation ?
I've mentioned that retaining compatibility is a restriction on this
implementation, I guess assuming the reasons were obvious. I've brushed
over them, but to be explicit, backwards compatible means multiple ini
settings, at least one userland function, module globals, and confusion.
It means being able to disable and enable assertions at _runtime_,
impacting the implementation and every op array that uses it in
_production environments_. All these things make the implementation less
suitable as an implementation of assertion and I do not see a need to
restrict it in this way.
Cheers
Joe
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
