Re: PHP RFC: Deffering functions by arguments (count or/and type)

From: Date: Fri, 22 Nov 2013 09:54:46 +0000
Subject: Re: PHP RFC: Deffering functions by arguments (count or/and type)
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-70280@lists.php.net to get a copy of this message
Johannes, thank you for your complete response. I've made a complex brainstorm with my colleagues and with a local community ( http://habrahabr.ru/post/198980/). So it took a long time. Nevertheless I've gotten an answers to your questions. And here they are. We need to implement two new modifiers: *override* and *dynamic*. The first one should be used to designate a function which overrides it's parent: *override public function* calcPerimeter() { ... } We are allowed to override only methods defined as *abstract* (without implementation) or *dynamic* (contains implementation). So the new modifier *dynamic* designates that function could be overridden and it has implementation. Here there is a code sample: https://gist.github.com/uaoleg/7596995 On Tue, Nov 5, 2013 at 10:21 PM, Johannes Schlüter <johannes@schlueters.de>wrote: > On Tue, 2013-11-05 at 19:22 +0100, Kevin Ingwersen wrote: > > I had nothing to do, > > With such statements be careful: A mail here goes to a thousand or so > readers, saving them time is notable and helps to get responses. > > > so here we go: > https://gist.github.com/IngwiePhoenix/e7fbee9f769fc137250d > > There are two things which have to be solved for this being possible: > > * There needs to be a backwards compatible way to handle the fact > that PHP functions accept variable amounts of parameters > currently > * This has to be implemented in a way not slowing down all > function calls > > For the first item think about code like this: > > class B { > function foo() { func_get_ars(); } > } > class E extends B { > function foo($bar = null) { func_get_ars(); } > } > $o = new E; > $o->foo(1, 2); > > With the logic from the idea B::foo() and E::foo() are different > methods, with current PHP they are overriding each other. Currently this > call E::foo(). what should happen After your change? Break lots of code? > > For the second item: Function calls in PHP are relatively slow already > and we have no good way to "bind" the calls during compilation so we > always have to resolve the call at run time. Consider this: > > function foo(someInterface $o) { > $o->method(); > } > > There we don't know which method to call. Unless there is a good idea > and a patch I expect this to slow down each and every function call. > which in my perspective is a no-go. Languages like C++ "mangle" the > parameters in the function name, which is complicated ina dynamic > language lie PHP, and have more information (when compiling that sample > function above PHP doesn't need the definition of someInterface, yet, it > might not exist, yet) Maybe somebody has an idea for a good > implementation. But till then I'd put this aside. > > johannes > > > >

« previous php.internals (#70280) next »