On Mon, Sep 19, 2011 at 1:21 AM, Pierre Joye <pierre....@gmail.com> wrote: > 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.
What do you think about finding consensus and fixing it for trunk? I think that consistent behavior between "normal" and abstract classes would be good. We could also improve the current method signature restrictions(many of us agree that it is too strict in some cases) and changing the E_FATAL something less grave was also mentioned. I could write up an RFC from the thread and my previous email for the allowed and restricted method signature overriding, and maybe Pierre also want to create an RFC for the method overloading. -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
