Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:24812
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Fri, 21 Jul 2006 11:30:34 +0200 (CEST)
To: Mike Bretz <m.bretz@metropolis-ag.de>
cc: internals@lists.php.net
In-Reply-To: <44C09BE7.2010105@metropolis-ag.de>
Message-ID: <Pine.LNX.4.62.0607211129270.5096@localhost>
References: <EB.71.29121.B6690C44@pb1.pair.com> <44C09BE7.2010105@metropolis-ag.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: [PHP-DEV] RfC: rethink OO inheritance strictness
From: derick@php.net (Derick Rethans)

On Fri, 21 Jul 2006, Mike Bretz wrote:

> Michael Wallner wrote:
> > mike@honeybadger:~/build/php-unicode-debug$ cli
> > -d"error_reporting=8191" -r 'class c{function f(){}} class d extends
> > c{function f($a){}}'
> > Fatal error: Declaration of d::f() must be compatible with that of
> > c::f() in Command line code on line 1
> >
> >
> > I *really* think that this enforcements are no good idea and I _beg_
> > you that we leave this "area" to interfaces.
> +1
> 
> In real live "C++" world I often have parent classes with function f()
> and an extended class which also uses the function name f(..) but with
> other, possibly class specific, variables, which then calls parent
> f()... I do not see a good reason to enforce that both functions must be
> exactly the same when extending, especially since c::f() does not get
> called automatically, _when_ overwriting it in class d.

It's quite a different thing in C++ as there you have method overloading 
which PHP doesn't have. Therefore your argument doesn't hold here as 
they are simply *two different* methods, and not an overriden one. In 
your code that uses the derived class you can still use both methods 
(one without, and the one with parameters).

Derick