Hi! On 9/18/11 11:23 AM, Nikita Popov wrote:
I didn't see any complaints about this "feature", so I don't really see a reason why we should break BC with 5.3 here and drop the error message.
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.
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 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, which does not bear any practical purpose. Abstract methods define a contract between designer of the base class and implemetor of the concrete class. However, I do not see why this contract should state that you can never relax restrictions on your methods or ignore parameters or accept more than base class would allow you to accept.
to tell you: I need this and that method accepting these and these arguments to work correctly. If the signature isn't enforced, this doesn't make sense anymore. You could just as well drop the signature from abstract method definitions, as it's pointless then.
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".
-- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
