Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68977
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.181 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAF+90c8qj_3is8Dj4XbkUwL1Y8eVCEPXVYfwhDdaabHWuGzY2Q@mail.gmail.com>
References: <CAF+90c85v_VTPTPanBcTJ70Ff6pm6fRgAGs4n1uoaA+B9UZg=w@mail.gmail.com>
 <CAF+90c8qj_3is8Dj4XbkUwL1Y8eVCEPXVYfwhDdaabHWuGzY2Q@mail.gmail.com>
Date: Mon, 9 Sep 2013 20:39:19 +0100
Message-ID: <CA+yzxZh0H6rqf3wdzGVjGJs+iaMajgHgNqSMkq=fsiR4eZfkaA@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] Re: [RFC] Named parameters
From: admacedo@gmail.com (Daniel Macedo)

Nikita,

I agree with your views, although, I think your last suggestion comes
close to being close to some sort of weird method overloading (the way
I understood it).

I'd expect B::foo() to throw a warning/error and maybe stop there, and
you're considering reaching to the parent method to see if that
signature matches the function call...

While method overloading would be interesting to have (see previous
discussions on the matter ;)) this is a sort of weird and unexpected
reaching-back behaviour... I'm not sure this seems like a logical
approach, I say stick with the error and expect a consistent usage of
the (rewritten) API and prevent obscure bugs where you change an
implementation and rewrite param names when in fact you should stay
consistent with the existing code if you're extending existing
behaviour!

In fact I'm not sure if the other way around should be the norm; where
we'd force the dev to implement the *same* args as the parent (like it
is now: i.e. type hinting, same signature, etc); even if it's just to
do an unset($oldbar) inside something like B::foo($newBar, $oldBar =
NULL)

Was that clear?

Thanks,
Daniel Macedo