On Sun, 14 Sep 2014, Andrea Faulds wrote:
>
> 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.
But this "compromise" introduces yet another set of casting rules. And
that is why will advocate and vote against this.
We can either have casting where:
function bar(int $foo) { }
bar("42");
Means the same as:
function bar($foo) { }
bar((int) "42");
Or we can have it as a strict cast, or we can have it like it currently
(ie, not at all). I can live with those three options, but not an
option where casting/checking does something different again.
cheers,
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
