Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:25107
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <5D.33.45114.9A960D44@pb1.pair.com>
To: internals@lists.php.net
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>
Date: Wed, 2 Aug 2006 10:59:37 +0200
Lines: 79
Subject: Re: [PHP-DEV] RfC: rethink OO inheritance strictness
From: r.korving@xit.nl ("Ron Korving")

If I might make a suggestion...

I see two camps here, one in favor of freedom and others in favor of 
reliability in inheritance. I think both make good points. Maybe there is a 
way out that can please both and even another group of people.

Maybe, for PHP6, it's an idea to start supporting function overloading. I 
know this is problematic because of func_get_args(), but I think there's a 
way around that problem. I think it's extremely rare or perhaps never that 
people would want to combine function overloading and func_get_args().

So, my suggestion is this: why not support function overloading in PHP6, 
where functions can be implemented with different signatures. If a function 
is called with a number of arguments that does not match any of the 
implemented functions, an error is triggered if there is more than 1 
implementation of a function, otherwise that 1 function is called.

You can use different function signatures compared to parent classes, but 
abstract functions with a set amount of parameters really do need to be 
implemented with those parameters.

Hopefully with this situation everyone can be happy (including a group of 
people who would love to see function overloading).

Just a thought.

- Ron


"Lukas Smith" <lsmith@php.net> schreef in bericht 
news:E9.41.45114.FFB50D44@pb1.pair.com...
> Derick Rethans wrote:
>
>> On Tue, 1 Aug 2006, Robert Cummings wrote:
>>
>>> On Tue, 2006-08-01 at 23:41 +0200, Marcus Boerger wrote:
>>>> Hello Michael,
>>>>
>>>>   nobody forces you to use OO if you don't like it but it is as it is. 
>>>> And
>>> It is as it is, but not as it was. PHP4 allowed signature mismatching.
>>
>> Yeah, but PHP 4 didn't have OO support, so that argument doesn't count.
>
> Whatever .. then call it PHPOO .. either way it is obvious that:
> 1) proper OO code requires more planning. in the current context it means 
> that you need to put more time into planning your inheritance structure. 
> making sure that your parent has actually the most simple
> signature you will ever need, and expand on this interface in your 
> children.
>
> 2) it is simply often not feasible to change the parent inside a large 
> code base if you decide that its necessary to change the signature. 
> obviously this breaks the "is instance of" relation for that method. a 
> possible solution is to simply add a new method in this case. this is a 
> way out of the dilemma. however it means that you may end up adding 
> several methods and leaving in several that are likely to never be used. 
> and more importantly i have seen plenty of OO code that does not require 
> the "is instance of" relation for any or atleast all methods.
>
> remember PHP is a glue language .. to me this means it should stress 
> freedom above all. that being said i think it is also a good idea that PHP 
> is becoming a first grade language in its own right. however dropping its 
> ability to function as a rapid glue language is a bad idea. and i 
> personally have made good use of the PHP4 OO model and so just telling me 
> to go back to procedural is not acceptable.
>
> again i feel that people who want to use PHP as a "proper" OO language 
> will definately benefit from a strict mode if they are willing to put in 
> the extra planning. however alienating the userbase for this by making it 
> impossible to keep the old low planning OO style would be a bad idea.
>
> regards,
> Lukas
>
> regards,
> Lukas