hi, On Sun, Sep 18, 2011 at 9:06 PM, Stas Malyshev <smalys...@sugarcrm.com> wrote:
> There's no matter of "breaking BC" - there's no BC issues with dropping > error messages, nobody's code relies on generating fatal errors for specific > code. Btw, afair there is and was no BC as it was introduced with the abstract support. >> I already tried to explain why it makes sense: An abstract method is >> much like an interface. Both define signatures without implementation. >> If their signatures weren't enforces, what would abstract methods be >> good for? An abstract method (for me) is a way for an abstract class > > What's the point of "enforcing" such signatures? The key word missing here is "compatible". We enforce (or should) compatible signatures. And that makes totally sense. > The only point I know is > that you could call these methods with specific parameters and have it work. > In the example it is possible. Enforcing for the sake of enforcing is > meaningless purism, Are you saying that extending a class and making the constructor incompatible with the extended class is a good thing to allow and to do? If yes then I'd to strongly disagree with this idea as it allows very bad practices (and we have enough opportunities already to shoot ourselves in the head). > No it is not. The signature tells "this method would accept certain > arguments". If you call it with these arguments, it would work. However, > there's no promise to never extend the cases where it works - it goes > contrary to the whole point of OOP to say "I will never loosen preconditions > on my methods". And finally, the reason why abstract differs from the other areas is that they are newer. It was decided not to break BC for the other cases where we should have done the same. While Marcus wanted to do it everywhere, with the same good reasons. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
