> 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 <johncrens...@priacta.com> > From: Simon Schick [mailto:simonsimc...@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. >
