> De : Patrick ALLAERT [mailto:patrickalla...@php.net] > > 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?
Because strictness is not the overall objective the PHP language is aiming to. If it was the case, your mechanism would be fine, but deprecating ZPP conversion would be simpler and fine too. This is definitely not the same case as generating a notice on array to string (and why did you generate a notice instead of E_DEPRECATE, we would be rid of this crap now). That's what I hate in this 'weak' vs 'strict' terminology. It makes implicit that 'strict' is the natural future and improvement of 'weak'. That's absolutely not the case as 'weak' mode is not as negative as name suggests, and 'strict' is not so positive either. So, you may stop considering that the natural path for 'weak'-typed software is to migrate to strict types. When we decide encouraging migrating to strict mode with a deprecation on ZPP conversion, I hope I'll be far away... > PS: your feedback makes me feel it would be; even more; a viable option :) Fine. But may I remind you the so-called great benefit you underlined in your post is totally wrong and shows total ignorance of the difference between casting and ZPP conversion rules which, IMO, is a fundamental pre-requisite before laughing at people working on this. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
