Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:9367
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Reply-To: zeev@zend.com
Message-ID: <5.1.0.14.2.20040419130523.04e3fe60@localhost>
Date: Mon, 19 Apr 2004 13:14:40 +0300
To: Andi Gutmans <andi@zend.com>
Cc: internals@lists.php.net
In-Reply-To: <5.1.0.14.2.20040419125745.03b818c8@127.0.0.1>
References: <5.1.0.14.2.20040419112627.03efaa00@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [PHP-DEV] Interface inheritance
From: zeev@zend.com (Zeev Suraski)

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.  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...

Zeev