Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68989
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.174 as permitted sender)
MIME-Version: 1.0
Sender: happy.melon.wiki@gmail.com
In-Reply-To: <CAF+90c_Ygb7TrDp7uv-0J4s7AVO20Z9OwkXW4XMN6DQDt3bFog@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>
	<CAF+90c_Ygb7TrDp7uv-0J4s7AVO20Z9OwkXW4XMN6DQDt3bFog@mail.gmail.com>
Date: Tue, 10 Sep 2013 09:46:09 +0100
Message-ID: <CAFKLSKA7fV4N1oU3pcnXk=b+bNCepqf5-hvqRQz_tKqg_tSm0Q@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Daniel Macedo <admacedo@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7bb0473447c19b04e60389f1
Subject: Re: [PHP-DEV] Re: [RFC] Named parameters
From: happy.melon.wiki+gb@gmail.com (George Bond)

--047d7bb0473447c19b04e60389f1
Content-Type: text/plain; charset=ISO-8859-1

What about:

    class Giant {
        public function foo( $height, $width ) { ... }
    }

    class FallenOverGiant extends Giant {
        public function foo( $width, $height ) { ... }
    }

There's nothing to stop you doing that; I think it's actually done in some
of the codebases I work on.  Or:

    class Rectangle {
        public function paint( $height, $width ) { ... }
    }

    class Square extends Rectangle {
        public function paint( $width, $unused = null ) { return
parent::paint( $width, $width }
    }

Here I don't *want* someone to be able to use the second parameter (you can
argue over whether the inheritance should be that way round, but that's the
way code is currently written).

I don't think there's a clever way of pleasing everyone here.  In which
case, the principle of least surprise definitely applies.  Crawling the
inherited signatures definitely feels like a shim rather than clever design.

--G



On 9 September 2013 23:27, Nikita Popov <nikita.ppv@gmail.com> wrote:

> 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
>

--047d7bb0473447c19b04e60389f1--