Re: PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)

From: 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. >

« previous php.internals (#58398) next »