Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:9391
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Mon, 19 Apr 2004 20:49:33 +0200
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <101121849562.20040419204933@marcus-boerger.de>
To: Zeev Suraski <zeev@zend.com>
Cc: Andi Gutmans <andi@zend.com>, internals@lists.php.net
In-Reply-To: <5.1.0.14.2.20040419130523.04e3fe60@localhost>
References: <5.1.0.14.2.20040419112627.03efaa00@localhost>
 <5.1.0.14.2.20040419130523.04e3fe60@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Interface inheritance
From: helly@php.net (Marcus Boerger)

Hello Zeev,

Monday, April 19, 2004, 12:14:40 PM, you wrote:

> At 13:04 19/04/2004, Andi Gutmans wrote:
>>Hey,
>>
>>I just wanted to note the fact that I disagree with this.
>>In a perfect world, I would go with an E_COMPILE_ERROR in all situations; 
>>when inheriting regular classes (w/o abstract methods), abstract methods 
>>and interfaces. That is what the academic part of me feels but knows can't
>>be done.
>>As this would break BC too much, I agree that inheriting from regular 
>>classes should not lead to an error. I believe that for consistency sake 
>>interfaces and abstract classes should behave the same as regular classes,
>>thus, if regular classes don't cause an error, the former also shouldn't.

> Just to clarify a bit on why I think that we should differentiate:
> 1.  First of all, I agree that in a perfect world we should go with 
> E_COMPILE_ERROR for everything.  Maybe now that's constructors are out of 
> the picture, people will be more receptive to the idea - if we can go down
> that route, that option clearly gets my vote.
> 2.  If going for E_COMPILE_ERROR in all situations is not an option, then I
> do see a significant difference between interface/abstract methods, and 
> real methods, when it comes to inheriting from them.  The whole 
> interface/abstract/class type hints mechanism was added for the sole reason
> of enforcing prototypes, and effectively, it is pretty much useless the way
> things are now.

repeat useless.


> If we re-enable fatal errors for interface inheritance - 
> we give OO programmers the ability to enforce prototypes.  They would have
> to use an interface (or an abstract class) in order to do so, since it 
> won't be enforced for just plain classes - but at least they'd have this 
> option.

> To make it clear, my vote still goes for option #1, if people feel better 
> about it now...

fellBetter++

Doesn't this bring us back to the option to couple the severity for 'normal'
methods (no interface/abstract/typehints btw easily detecable by a new
fn_flag) with the ini setting for the engine's bc mode?


Best regards,
 Marcus                            mailto:helly@php.net