Hi, another end-user perspective:
Am Montag, 24. Mai 2010 14:12:41 schrieb Zeev Suraski: > At 14:48 24/05/2010, s...@geleia.net wrote: > >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. > > We can agree to disagree regarding the level of understanding the > average PHP developer has about zval.type - but it doesn't change my > opinion that strict type checking would be the biggest inconsistency > in PHP's core syntax ever. These two assertions are independent from > each other. I don't know if I have a full understanding about zval.type on internal C-level. But in my code I always use strict type checking in comparisons and in functions like in_array that offer that possibility. That's because I learned the hard way how much debugging time it saves if I handle my variable types with care. (Things like '11111111111111111' == '11111111111111112' evaluating to true on 32 bit don't make it better.) I'd say: the type-juggling is not the *big plus* of PHP. BTW: if I read some "PHP is so enterprise-ready" articles, I never read about the advantages of weak types. (I'd even liked it, if there would be an optional(!) possibility of variable type declaration. Who cares, could use it - others ignore it.) In contrast to "normal" PHP behavior where the user doesn't care about variable types, with type hinting in methods/functions it is explicit what's required. Every non-strict type handling is contra-productive. So if someone wants to use my function with hints, he needs to care about his types. My opinion: - Don't introduce another kind of type juggling related to type hinting - that's making it worse because many users won't know/see/understand the differences. - If it's not strict, I don't see a real advantage of type hinting (besides static code analysis and no need to declare types in doc blocks). - If you want to support weak type hints, declare strict and weak hints. Because I like strict type checks. And I don't see, why I shouldn't be able to have strict checks but others that do not care about their types should have something that looks like type hinting. (I guess, they won't use it anyway if they don't care about types.) PHP offers both ways of strict and weak handling with comparisons and some functions - so it should offer both ways here as well. - If you don't want to distinguish beetween strict and weak hints, create some ini setting that influences the behavior. (I'm not a fan of that.) - I see that there will be problems when a developer, who doesn't care about types, wants to use an external library with strict hinting. So perhaps the way to go is: provide strict and weak hinting plus an ini setting to reduce strict to weak hints if someone wants to include a "strict" library. (I guess the other way round - make weak hints to strict hints - is probably not so usefull, as I can't rely on a library with weak hinting to be 100% strict hinting compliant internally.) I hope this post is not to offensive. Just wanted to make my point clear that I want to be able to use strict hinting, because I don't like the weak types regarding software quality. (No, I'm not using the wrong language.) Regards, Thomas > > >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. > > Suggest we put aside the 'is strict typing better than variant X of > auto-conversion or not' discussion since it's mostly academic. I > think we both agree that we need to find the best version of > auto-conversion. > > >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. > > Sounds acceptable to me, that's along the lines of the 3rd option > which appears to be getting the most traction. I'd also no > conversion of arrays to scalars to that list. > > Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
