On Mon, May 24, 2010 6:09 am, Zeev Suraski wrote: > At 03:53 24/05/2010, s...@geleia.net wrote: >> On Sun, May 23, 2010 9:33 pm, Etienne Kneuss wrote: >>> On Sat, May 22, 2010 at 17:04, Zeev Suraski <z...@zend.com> wrote: >>> >>>> As one of the key people who designed PHP's type system I consider >>>> strict type checks completely alien to and counterintuitive in PHP >>>> and am therefore pushing to implement 'weak' typing instead, in a >>>> way that's consistent and familiar to users. >> >> I agree. I added to the RFC a table with the current behavior of >> current behavior of zend_parse_parameters (not sure if I should, feel >> free to move it elsewhere). There are many differences between two. I >> think the conversions should either be the same or it should be strict. >> >> Are users supposed to distinguish "string" as it appears in the >> documentation from this new "string" in the functions' declaration? >> Adding another inconsistency to PHP is not a very good idea, in my >> opinion. > > I have to say that I don't really see the logic in "either it should > be identical to PHP's conversion rules or it should be 100.000% different > (strict)". Adding strict typing would be the largest > inconsistency in PHP's core syntax, ever.
I disagree. The === operator already checks the type of the variables. Saying that the PHP programmers shouldn't have to worry about the type of the variables (that it's just an implementation detail) is pure fantasy. Let's say I want to check whether some arbitrary user input is 0. if (array_key_exists('quantity', $_POST) && !is_array($_POST['quantity']) && $_POST['quantity'] == 0) { ... } Now I have the condition evaluate to true if the user input was "abc". I'm sure I come up with lots of examples where the type is important in PHP and the programmer must be aware of it. > For that reason, I prefer pretty much any variation of the proposed > solution over strict type checking. > > I see three key options going forward: > 1. Implement the table along the lines of what it looks like now, > perhaps with minor changes. > 2. Implement identical conversion rules to the > ones that exist in PHP; That effectively turns type hinting into scalar > casting operators (not saying that's a bad thing!) > 3. Implement identical conversion rules to the ones that exist in PHP, > except for when they really suck. Namely, lose the array->scalar > conversions and silent conversions of non-numeric strings to numbers. > That said, I don't think strict type checking is the best option. I just think it's better than inventing a new complex set of rules that are inconsistent with everything else. Otherwise, an "int" could mean that the type is int (is_int), that zend_parse_parameters would accept it with the flag "l" or "L", or that it is an int in this new weak sense. Maybe we could also add "is castable to an int" (which works with arrays, but not with objects unless they implement get/cast). That would put us at 4 different meanings. I think the best option is to align the type checking with zend_parse_parameters (this is not the same as an implicit cast) and make it stricter. This includes: * disallow string to float/int when it contains non-numeric characters (includes "123abc") * disallow string/float to int when it causes overflow instead of the current behavior (triple cast (long)(unsigned long)(long long)). "L" would retain the current behavior. Although a depart from backwards compatibility, I doubt this would cause much brekage. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php