Hi! On 9/18/11 4:21 PM, Pierre Joye wrote:
The key word missing here is "compatible". We enforce (or should) compatible signatures. And that makes totally sense.
foo() is compatible with foo($a, $b) - since anywhere you can call function declared as foo($a, $b) you can also successfully call one declared as foo(), it'd just ignore extra parameters - but it is not allowed (I gave an example). It was bad when it was a useless E_STRICT, it is much worse when it's a fatal error.
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
I never said anything about constructor being "incompatible" with extended class and it being good thing. I am saying rejecting compatible but not matching signatures - and I gave example of foo() vs foo($a, $b) - makes no sense. And not even with E_STRICT - it's a fatal error now!
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.
I guess "all abstracts do that" is better than "abstracts except for ctors do that" but only marginally as both behaviors make little sense to me. Being restricted to abstracts limits the BC impact (as people could just remove the abstract keyword and thus avoid trouble relatively easily) but in both cases it doesn't look too good.
I'm not sure if we should keep the new BC-breaking error in 5.4 for consistency sake (I'd felt much easier if we had discussed that before - or we did and I just forgot?), but I seriously think we need to rework it in 5.5 and make all compatible signatures work without complaining.
-- 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
