Hi Adam > 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? 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). cheers Dan On Fri, Sep 6, 2013 at 8:16 PM, Adam Harvey <ahar...@php.net> wrote: > On 6 September 2013 12:12, Dan Ackroyd <dan...@basereality.com> wrote: > >> If named parameters are introduced, signature validation should include > >> parameter names. Throwing a fatal error (for the interface/class > > combination) > >> would break backwards compatibility though. We could use some lower > error > >> type... > > > > Would it be possible to set the error level through an ini setting? Or > > disable it entirely? > > I've said this before, but to reiterate it: I'd be a huge -1 on > anything that involves configurable language behaviour. It's a support > nightmare, and I'm glad those days are now mostly over. > > > People who are writing new code that is aware of named parameters should > > want a fatal error for any coding mistake that violates the contract. > > 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. > > Adam >
