On 14 Sep 2014, at 13:17, Zeev Suraski <z...@zend.com> wrote: > I honestly don't see why we can't be consistent for the simple types, or > at least strive to be as consistent as possible as opposed to introducing > a complete parallel universe for userland functions, that's inconsistent > with the entirety of the rest of PHP. We don't have to be consistent with > ALL internal functions, which obviously have the option of doing custom > checks and return failures not only if you fail to, say, pass on a string > - but also if that string is not of a special format. But then, you have > the option of doing that also in userland functions using custom code. > The question is not the customized cases - it's the standard behavioral > cases - comparing zpp rules for scalars and the newly-introduced rules for > userland scalars.
OK, we could go for exactly what zpp does already. However, then we don’t have a compromise. We are siding with what you want, but most userland developers would prefer a strict system. While this would please you and perhaps some other folk on internals, and sure, it’d be consistent, it would not be popular with the wider PHP community. Similarly, we could go for a fully strict approach, which might please some userland developers, but wouldn’t please you. I don’t want to go down this route. I’d prefer we compromise and keep PHP’s weakly-typed nature (an int can be accepted as a float or a string), but make it stricter (no data loss), thus arriving at a middle way. > We could definitely strive to be consistent; Introduce some changes to > the implicit casting rules for internal functions and implement the very > same rules for this brand new userland functions. I'm definitely against > this RFC in its current form. I wanted to do that, but it has its problems. I do not have the time to go through and update literally thousands of tests that would be broken by zpp changes. Also, any change to zpp’s behaviour has backwards compatibility implications. There are some minor things I would like to change in zpp, which I will make an RFC for regardless of the success of this RFC (integer overflow should fail or at least raise a notice). Also, as I mentioned above, the resulting proposal would probably not please people who want strict types. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
