At 15:12 10/06/2010, Christian Schneider wrote:
Zeev Suraski wrote:
> That's exactly what I had in mind. Have E_TYPE off by default and
> implement it throughout PHP - instead of just type hints.
>
>> for example:
>> $foo = 0;
>> $foo += (int)'123abc'; // no error
>> $foo += '123abc'; // E_TYPE
Out of curiosity: What would you do with the E_TYPE on the last one?
1) Log it: What for?
2) Abort the script: Why?
3) Silence it with explicit casting: Why?
4) Look at the code and find out X: What is X?
Exactly the same thing you'd do with notices regarding uninitialized variables.
If someone turns E_TYPE on, it's a pretty strong implication that he
expects his code to be 'type clean', i.e., that each and every value
will be sanitized and have the correct type. Chance are that seeing
an E_TYPE in such a case would prompt him to fix his code (either by
silencing - unlikely - or by fixing his type/value verification.
My guess is that it is theoretically useful if you ensure that all your
normal code is E_TYPE-free and user provided input could trigger E_TYPE
which would require special code to be added in that case to avoid
future E_TYPE.
Right.
One biggy for me: E_TYPE should not slow down PHP if one is not
interested in it. I think there was a discussion about making ignored
E_* (almost) performance neutral but I don't think that's implemented
yet, right? We patched away E_NOTICE warnings in the PHP source because
we're not interested in access to undefined variables and I wouldn't
want to have to do something similar for E_TYPE.
I agree we should only add E_TYPE if it's almost performance
neutral. IIRC that would require some work.
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
