Re: RfC: rethink OO inheritance strictness

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