> De : Anthony Ferrara [mailto:ircmax...@gmail.com] > > I've taken a look at that proposal, and here are my comments:
Thanks > 1. This RFC only talks about ZPP. I assume you're also talking about > exposing the same ruleset to userland? Right. This is a sub-RFC of STH main. As it is stated in introduction, STH is based on ZPP and follows its ruleset. > 2. You're talking about making passing `1` to a bool parameter > disallowed by default. Meaning that a **LOT** of code will break > automatically when upgrading to 7. Because internal function's error > behavior will change. 2 days ago, we took time to discuss about this, and decided we should proceed in several steps : 1. Implement a first version of the ruleset and ask list members to pre-validate on different PHP software. Massive BC breaks would appear quickly. 2. If massive BC breaks appear, find a minimal way to fix, while keeping ruleset consistency. The only case we were hesitating about for a first test is conversion to bool. I initially proposed to keep existing rules, just extending (string -> bool) to consider *every* numeric string that would give a null number should be converted to false, not just "0". Thought it was necessary because, today "0" and " 0" give (int)0, but "0" is false and " 0" is true. Zeev didn't like this, so consistency dictated to start with (string/float/int -> bool) totally disabled, and check for massive break IRL. I didn't want to make it a voting option because I feel like you about voting options. Now, your opinion confirms that time is probably too short to organize such test before vote begins. So, I'll modify the RFC to revert back to what I explained above. If people allow, I'll try to stick to the (string -> bool) minor modification I wanted to propose, but that's detail. > If you were just talking about user-land types, that would be one > thing. But since you're explicitly talking about ZPP, this is a bad > thing. As previously said , I won't propose userland-only rules, except probably 'resource' to accept IS_RESOURCE and IS_OBJECT, but that's different story. > 3. It still doesn't solve the problems the strict type proponents are > looking to have solved (namely that the type is what's checked, not > the value). The is_numeric_string cleanup is definitely a step in the > right direction (and I think should be implemented anyway), but it > still doesn't solve the problem. We all agree here. Cannot use type-only if "31" accepted as 31. I could just limit value to be used in as few cases as possible, but it is not a complete no-go in my opinion as it just forces a tool to consider 'int' as a potential union of IS_STRING|IS_LONG|IS_FLOAT, instead of IS_INT. As any tool analyzing PHP code will have to support some unions like this, it will cause some cases to be undetected but it does not kill the concept of static analysis for PHP. There are also lots of ways to restrict possible zval types by analyzing the code. Remember arguments are systematically converted to known zval types on function entry, this helps a lot. I won't go further because you're an expert on the subject and I'm not. > Overall, this proposal feels like a compromise in a bad way. It makes > existing code error (bc break), doesn't give the weak proponents what > they want Examples of not solving weak proponent needs (except conversion to bool which will be reverted) ? > and doesn't give the strict proponents what they want > either. Just because it's the middle ground doesn't make it a good > thing. Not perfect, yes, but I still favor the approach, compared to the assertion that 1 proposal + 1 proposal takes the best of both. > Please consider these issues seriously prior to making the proposal official. We are talking draft. Not sure yet it goes official one day. Thanks François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
