On Sun, Jul 05, 2009 at 11:30:28AM +0300, Zeev Suraski wrote:
> I think there's a more fundamental flaw here than just pointing to 
> 'numeric' as an alternative.  The internal IS_* setting is 
> meaningless for countless pieces of data floating around in PHP, 
> arguably far more than the ones for which it truly represents the 
> 'semantic' type.  Continuing what Stas said, it's no coincidence our 
> internal functions transparently translate arguments to the required 
> types (except for the rare cases where it's not possible).
> 
> The other course of action is to change the implementation so that it 
> behaves like the one for internal functions - with emphasis on 
> conversion instead of validation of IS_*.  We can consider being more 
> strict - and error-out on non-numeric strings instead of producing 
> 0;  If we were to start from scratch today, we'd probably do the same 
> for internal functions.  Encouraging the equivalent of strict is_*() 

Maybe that is something to consider:

PHP 6: warn on non-numeric strings, dependent on something in php.ini
PHP 7: error on non-numeric strings

If someone has some code that goes:
        $six = 3 + 'three';
then is isn't doing what they intend, so an error would be helpful.

The question is one of transition - breaking code that doesn't do input
validation, hence for a transition to help the better programmers.
As for the cr*p programmers - well their code was broken anyway.

> checks is very inconsistent with both our entire internal functions 
> library, as well as the common behavior of PHP.  It doesn't come to 
> say that it's not useful in some cases - but for these, using is_*() 
> should be a suitable.

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT 
Lecturer.
+44 (0) 787 668 0256  http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: 
http://www.phcomp.co.uk/contact.php
Past chairman of UKUUG: http://www.ukuug.org/
#include <std_disclaimer.h>

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to