Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68985
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CA+yzxZh0H6rqf3wdzGVjGJs+iaMajgHgNqSMkq=fsiR4eZfkaA@mail.gmail.com>
References: <CAF+90c85v_VTPTPanBcTJ70Ff6pm6fRgAGs4n1uoaA+B9UZg=w@mail.gmail.com>
	<CAF+90c8qj_3is8Dj4XbkUwL1Y8eVCEPXVYfwhDdaabHWuGzY2Q@mail.gmail.com>
	<CA+yzxZh0H6rqf3wdzGVjGJs+iaMajgHgNqSMkq=fsiR4eZfkaA@mail.gmail.com>
Date: Tue, 10 Sep 2013 00:27:22 +0200
Message-ID: <CAF+90c_Ygb7TrDp7uv-0J4s7AVO20Z9OwkXW4XMN6DQDt3bFog@mail.gmail.com>
To: Daniel Macedo <admacedo@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e011830665792e704e5fae470
Subject: Re: [PHP-DEV] Re: [RFC] Named parameters
From: nikita.ppv@gmail.com (Nikita Popov)

--089e011830665792e704e5fae470
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Sep 9, 2013 at 9:39 PM, Daniel Macedo <admacedo@gmail.com> wrote:

> 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).
>

Uh, I think this is a misunderstanding caused by my bad phrasing. I'll try
to clarify:

    class A {
        public function foo($oldBar) { ... }
    }

    class B extends A {
        public function foo($newBar) { ... }
    }

    $b->foo(oldBar => $xyz);

Here `$b->foo()` will call `B::foo()`, *not* `A::foo()`. The thing about
looking at the parameter names of the parent methods is just to make sure
calls are compatible with the parameter names of parent methods, even if
those names were changed during inheritance. We do not actually call the
parent method, we just borrow the parameter name from there.


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)


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.

Nikita

--089e011830665792e704e5fae470--