Re: PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
| From: | Lazare Inepologlou | Date: | Thu, 01 Mar 2012 09:10:02 +0000 |
| Subject: | Re: PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting) | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-58398@lists.php.net to get a copy of this message | ||
> That's what I was calling "inconsistent", specifically because
> (int)'foo'
> == 0 with no warning whatsoever, but int $a = 'foo' would be 0 with an
> error of some sort. Behavior with respect to when an error is raised is
> inconsistent. In both cases there is a very lossy conversion, why is there
> an error in one case and not the other? Inconsistent.
>
+1
However, I would love to have int $a = 'foo' cast to 0 without any error.
New functionality without breaking BC.
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/3/1 John Crenshaw <johncrenshaw@priacta.com>
> From: Simon Schick [mailto:simonsimcity@googlemail.com]
> >
> > Hi, John
> >
> > Just to add an idea to yours ..
> >
> > Do you think it's a compatibility-break if we'd decide to send a
> E_NOTICE or E_WARNING if we f.e. try to give a string to a method that just
> allows integer for this argument?
> No break at all, just a E_NOTICE or E_WARNING as the script can succeed
> anyways.
> >
> > Bye
> > Simon
>
> That's what I was calling "inconsistent", specifically because
> (int)'foo'
> == 0 with no warning whatsoever, but int $a = 'foo' would be 0 with an
> error of some sort. Behavior with respect to when an error is raised is
> inconsistent. In both cases there is a very lossy conversion, why is there
> an error in one case and not the other? Inconsistent.
>
> On the other hand if you add an error in the legacy case now that's a BC
> break. One might argue that it should always have given a notice, but it
> didn't, so it's a change, and a BC break. Pick your poison.
>
> John Crenshaw
> Priacta, Inc.
>