Re: Re: [RFC] Named parameters

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 >