Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68924
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain basereality.com from 74.125.82.177 cause and error)
MIME-Version: 1.0
In-Reply-To: <CADajX4Db3z8FMKJEs7Uy7dr9MKmo4uJJ1c3E_dntr9Di7bOb7g@mail.gmail.com>
References: <CAF+90c85v_VTPTPanBcTJ70Ff6pm6fRgAGs4n1uoaA+B9UZg=w@mail.gmail.com>
	<CA+kxMuSm0x26j4L5tyn_b1HxPkTKNZx2sTSG7qLKHpgrQNu3MA@mail.gmail.com>
	<CADajX4Db3z8FMKJEs7Uy7dr9MKmo4uJJ1c3E_dntr9Di7bOb7g@mail.gmail.com>
Date: Fri, 6 Sep 2013 21:01:13 +0100
Message-ID: <CA+kxMuQKKpRvWVqkmaSXoTApnqdhHCnm+Px78Gwf2FzvswXniw@mail.gmail.com>
To: Adam Harvey <aharvey@php.net>
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e011600982ef25904e5bc8019
Subject: Re: [PHP-DEV] [RFC] Named parameters
From: danack@basereality.com (Dan Ackroyd)

--089e011600982ef25904e5bc8019
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

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 =97 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 <aharvey@php.net> wrote:

> On 6 September 2013 12:12, Dan Ackroyd <danack@basereality.com> wrote:
> >> If named parameters are introduced, signature validation should includ=
e
> >> 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 shoul=
d
> > 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 =97 that's
> certainly been true everywhere I've worked that's had a "modern"
> codebase.
>
> Adam
>

--089e011600982ef25904e5bc8019--