> If it errors out or throws an exception, it's strict typing, regardless of
> naming.
Actually, for purposes of this discussion, "strict" is defined. It means "PHP
complains about (function(int $n){})('1'), even though it could have easily
converted it." The majority of arguments in the past, and especially those that
have caused the typing discussions to fall apart, have centered around reasons
why this sort of typing is bad. Strict, by this definition, is totally off the
table in this discussion. Period.
With respect to E_RECOVERABLE_ERROR, nobody seems especially attached to this,
except that it is consistent with current type hints, so it is the logical
choice. A consistent alternative would be a new E_TYPE error (and convert
existing type hints to use that), but that would be a BC break and expands the
scope of the proposal more than I think some people are comfortable with
(myself included).
> Are you essentially telling us we all have to waste our time again just
> because 6 months have passed?
No, we're discussing this again because for the first time we have a set of
terminology that we can use to explain how this is different from the terror
that has primarily been avoided in the past.
I'm in favor of moving the discussion elsewhere while details are fleshed out
and carefully compared to the historical arguments, but so far there has been
no consensus on where to move this.
I'll personally resist any attempt to submit anything that isn't substantially
different from prior proposals and/or that doesn't include solutions to the
problems previously identified.
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
