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 <[email protected]> wrote:
> On Mon, Sep 9, 2013 at 9:39 PM, Daniel Macedo <[email protected]> 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
>