Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:9396
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
In-Reply-To: <101121849562.20040419204933@marcus-boerger.de>
References: <5.1.0.14.2.20040419112627.03efaa00@localhost> <5.1.0.14.2.20040419130523.04e3fe60@localhost> <101121849562.20040419204933@marcus-boerger.de>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-ID: <0EB7FB18-923B-11D8-8782-000393B2B3C0@omniti.com>
Content-Transfer-Encoding: 7bit
Cc: Zeev Suraski <zeev@zend.com>,
 Andi Gutmans <andi@zend.com>,
 internals@lists.php.net
Date: Mon, 19 Apr 2004 15:52:15 -0400
To: Marcus Boerger <helly@php.net>
Subject: Re: [PHP-DEV] Interface inheritance
From: george@omniti.com (George Schlossnagle)


On Apr 19, 2004, at 2:49 PM, Marcus Boerger wrote:

> 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.

+1

>> 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.

yep.

>> To make it clear, my vote still goes for option #1, if people feel 
>> better
>> about it now...
>
> fellBetter++

I also think this is the way to go.

George