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
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
