Re: RfC: rethink OO inheritance strictness
| From: | Richard Lynch | Date: | Wed, 02 Aug 2006 17:32:09 +0000 |
| Subject: | Re: RfC: rethink OO inheritance strictness | ||
| References: | 1 2 3 4 5 6 7 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-25140@lists.php.net to get a copy of this message | ||
On Wed, August 2, 2006 5:30 am, Hartmut Holzgraefe wrote:
> Ron Korving wrote:
>
>> So, my suggestion is this: why not support function overloading in
>> PHP6,
>
> because in PHPs dynamicly typed world this would require runtime
> checks *on every single function call* as things can't be resolved
> at compile time?
Yes and no.
The Lisp guys have dealt with this issue for DECADES and have several
slick work-arounds to optimize this checking.
First, you *CAN* check the number of args at compile time, and reduce
your search-space considerably that way.
Lisp also caches the inheritence order for which method to call "next"
for multiple-inhertence classes.
I believe that method signatures could also be cached on class
definitions in such a way that it would NOT drastically affect
performance to check which method to run.
So while the checks would need to be done at run-time, the information
to lookup which method to call could be reduced to a minimal lookup
routine of O(1) or O(log N) or somewhere in that range, where N is the
number of ancestors.
There is no need to rule out using func_get_args() -- Once the method
whose signature matches has been called, there's no reason why
func_get_args() could not be utilized to process the args that
"remain" for a matching signature. I.e., a method signature would
"match" if the parameters list matches the corresponding arguments --
and any additional arguments need not be considered a failure to
"match"
This would probably best be done in PHP 7 rather than 6, I should
think -- but it's a VERY good reason to not paint ourselves into a
corner with OOP strictness today which will have to be violated with a
BC-breaking change somewhere down the road when polymorphism is
supported.
If we want to condemn PHP to *never* support polymorphism, then
enforcing the parameter lists to match seems less problematic -- But
if there's a gleam in the eye for polymorphism "some day" this
restriction seems a bit short-sighted to me.
--
Like Music?
http://l-i-e.com/artists.htm