Hi, 2015-02-12 0:08 GMT+01:00 Zeev Suraski <z...@zend.com>: > It gives the exact same > value from an API author’s point of view.
But not from an api-consumers point of view. Without either introducing a new set of casting/conversion rules or changing existing behavior (**exclusively**) 'weak' typehints may be perceived as seriously crippled. Maybe up to a point where the addition of them wouldn't be justified. > But unlike the current RFC, v0.1 doesn’t introduce an IMHO alien concept > into a language that considered dynamic typing to be a core principle since > its birth. It's not. PHP was always open to enforce strict typing in user created functions. If types didn't matter the way they do the current distinguishing between int/float or respectively array/stdClass/Objects shouldn't exist. But thankfully they are distinctive. The proposal offers a way to conditionally harmonize different usage patterns. (Across code bases and with internal functions) Having the ability to conditionally tighten rules in self written code but falling back to loose (in many cases good, in other cases disastrous) behavior is what modern PHP defines. To much new code already enforces strict types. Using if(!is_int) throw new WrongArgumentTypeException() or similar. The proposed RFC could unify such codebases. Having typehints in the proposed form would allow the api creator to drop most additional type checks as the method always receives what was asked for and shifts responsibility to the user. The way how an API is used would be determined by the user, allowing them to continue to use the weak behavior if they want but also offer them to enforce the rules that otherwise the api creator might force on everyone. Why don't you want to allow people to use (formerly your) language in the way they see fit as you have already given them the broader framework do to so. Having optional strict hints together with the performance improvements and the maturing php ecosystem (composer/fig/co. + enterprise-targeting frameworks) may even attract new users to php that don't want or require the mental burden or the ecosystem given by other languages(java,c#) but don't want to miss the additional safety and feeling of strict types. The other options (globally changing zpp rules and the behavior of implicit casts) sharing most of the advantages implied in the current proposal was already proposed as RFC and talked down as the BC break was considered to big. The concept behind the current RFC (not so much the syntax) is the only way to satisfy both camps without alienating a large part of the community. I'd even argue that weak hints alone wouldn't be able to reach a 2/3 majority as strict supporters (Over 1/3rd of what I've seen on this list) would need be afraid that their preference would never reach the required majority once weak hints are in. It's this proposal, semi-strict hints or changed conversion rules (The alternatives would either introduce yet another set of unconditional rules or require a considerable BC break as noted above). Everything else will either not reach the required majority or will alienate potentially large parts of the user land community (Which aren't necessarily known to the oss community, zend or similar). Thanks -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
