Le Wed Feb 18 2015 at 19:10:54, Sara Golemon <poll...@php.net> a écrit :
> On Wed, Feb 18, 2015 at 7:34 AM, Patrick ALLAERT <patrickalla...@php.net>
> wrote:
> > Regarding 2) and 3):
> > An option might be to implement "weak mode" only and configure the
> coercion
> > rules "reporting" in a similar way than with the error_reporting
> > configuration entry.
> >
> > ini_set("coercion_reporting", 0); // current PHP 5.x behaviour
> >
>
> The significant problem with this is that it effects not only the
> current script, but also all callees (until the next time someone
> flips the bit).
>
That precisely my intention.
> So imagine LibraryA.php was written for PHP5, no scalar type hints,
> and all that comes with it.
>
> Your application turns on COERSION_WARNING and calling
> LibraryA::doStuff(1,2,3);
>
> That call is valid because you're a good programmer who reads the
> manual and knows how to pass the right args. The author of LibraryA,
> however, wrote it while drunk at a ruby meetup and is depending on
> weak conversions all over the place. They even need md5(array()) to
> output 4410ec34d9e6c1a68100ca0ce033fb17 (yes, I know we don't allow
> that anymore, enjoy the metaphor)
>
So, by turning it on, I would realise there is something wrong in my
"LibraryA"?
> My point is that it potentially imposes new warnings on foreign code.
>
Eureka :)
That's what happened when I introduced the "Array to string conversion":
lot of people complained about it and many frameworks had to fix various
issues where it happened under the hood (e.g.: with array_diff() on
multidimensional arrays).
My point is that the same is true when adding E_NOTICE, E_WARNING,
E_DEPRECATED,... to the error_reporting: it might prevent libraries to work
correctly (read: without extra PHP errors).
Why can't strictness follow that path?
PS: your feedback makes me feel it would be; even more; a viable option :)
Cheers,
Patrick
