Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:25140
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <8145.67.108.68.40.1154539929.squirrel@www.l-i-e.com>
In-Reply-To: <44D07EDE.4030001@mysql.com>
References: <EB.71.29121.B6690C44@pb1.pair.com> 
    <18810497049.20060801234124@marcus-boerger.de>
    <1154478748.6599.16.camel@blobule>
    <Pine.LNX.4.62.0608020940590.26373@localhost>
    <E9.41.45114.FFB50D44@pb1.pair.com> <5D.33.45114.9A960D44@pb1.pair.com>
    <44D07EDE.4030001@mysql.com>
Date: Wed, 2 Aug 2006 12:32:09 -0500 (CDT)
To: "Hartmut Holzgraefe" <hartmut@mysql.com>
Cc: "Ron Korving" <r.korving@xit.nl>,
 internals@lists.php.net
Reply-To: ceo@l-i-e.com
User-Agent: Hostbaby Webmail
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal
Subject: Re: [PHP-DEV] RfC: rethink OO inheritance strictness
From: ceo@l-i-e.com ("Richard Lynch")

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