Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68990
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.213.43 cause and error)
Message-ID: <522EF22F.1040006@lerdorf.com>
Date: Tue, 10 Sep 2013 12:19:27 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: Nikita Popov <nikita.ppv@gmail.com>
CC: Daniel Macedo <admacedo@gmail.com>, 
 PHP internals <internals@lists.php.net>
References: <CAF+90c85v_VTPTPanBcTJ70Ff6pm6fRgAGs4n1uoaA+B9UZg=w@mail.gmail.com> <CAF+90c8qj_3is8Dj4XbkUwL1Y8eVCEPXVYfwhDdaabHWuGzY2Q@mail.gmail.com> <CA+yzxZh0H6rqf3wdzGVjGJs+iaMajgHgNqSMkq=fsiR4eZfkaA@mail.gmail.com> <CAF+90c_Ygb7TrDp7uv-0J4s7AVO20Z9OwkXW4XMN6DQDt3bFog@mail.gmail.com>
In-Reply-To: <CAF+90c_Ygb7TrDp7uv-0J4s7AVO20Z9OwkXW4XMN6DQDt3bFog@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: [RFC] Named parameters
From: rasmus@lerdorf.com (Rasmus Lerdorf)

On 09/10/2013 12:27 AM, Nikita Popov wrote:

> Yes, throwing an error during the signature validation is the "right" thing
> to do from a theoretic point of view. The issue is just that it breaks old
> code which didn't make sure that parameter names between parent and child
> lined up. "Break" is a bit too much here as it would still run, just
> throwing an E_STRICT. This is what I'd like to go for, but others disagree
> so I tried to offer an alternative solution.

It isn't feasible to suddenly start spewing E_STRICT errors on inherited
methods that change the name of the parent's arguments. The name of the
arguments has never mattered before and tons of code will no longer be
E_STRICT clean even if they don't use named parameters.

I think you are over-thinking this case actually. I would prefer to just
keep it simple. If someone does a named parameter call to a method that
doesn't have a parameter with a specified parameter it is an error,
regardless of how that came to be. If there is a parent method with the
parameter name, it doesn't matter since that is not the method they are
calling. Just keep it simple and generate an error just on that call.
The fix for the user in this case may very well be to go and make the
parameter names match the parent method, but let them worry about that.

-Rasmus