On 6 September 2013 13:01, Dan Ackroyd <dan...@basereality.com> wrote: >> I'd say the odds are that those sorts of users are going to be writing > >> code that is required to be notice/strict clean anyway — that's >> certainly been true everywhere I've worked that's had a "modern" >> codebase. > > Yes, so say you have a team that: > > * currently has a code base that is notice/strict clean > * wants to move to PHP 5.x which has named parameters > * have code which changes the param name in extends/implements > > Unless they rewrite their code, they wouldn't be able to upgrade next > version of PHP without losing their strict/notice cleaness. So how would you > suggest they upgrade to the version of PHP with named parameters?
At the risk of being glib, by cleaning up their parameter names. A team that's testing a PHP upgrade is likely capable of that, and the strict notices would give them the needed feedback in the early stages of testing. That's hardly a rewrite. > Also I'm not sure that having which error level is used actually changes the > behaviour of the language in a meaningful way. It only suppresses a > particular warning message, which can be suppressed anyway with > error_reporting(0). I don't really care which level actually gets used (it could be anywhere from E_STRICT to E_WARNING from where I sit), but I don't think the error reporting for a particular feature should ever be controllable separately from PHP's global error reporting. These sorts of warnings are there to promote better practice. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
