Andi Gutmans wrote: > Seems like I missed that whole thread. > I don't quite understand what we have to gain from dissallowing overriding > static methods and/or abstract static methods. It's not really in the PHP > spirit. > Making it E_STRICT doesn't solve the situation because it will tell people > it's not an ok thing to do, and I'm not quite sure that's what we want. > Can we revert to 5.1 status quo and get 5.2 shipped and discuss this? > Shipping it like this and then reverting later will just create a huge > headache and will confuse our user-base. > > Btw, I don't quite understand why it doesn't make sense? Maybe people are > not used to it from other OO langauges but the "no sense" argument isn't > very convincing. I actually see it as a way to enforce a contract or > structure. Some might not agree with it but I don't see how it violates any > rules of the universe... > Andi >
Hi Andi, Many other changes that were made to make PHP's OO more strict violate no fundamental rules of the universe. Yet they're now fatal errors. There have been several pleas not to go into the direction of more static language, but those pleas have fallen on deaf ears (see the latest one with subject "a last plead" from Lukas on internals). Stuff like accessing a non-existing class constant -> fatal error. Or creating a class variable that was not previously declared -> fatal error. Or changing method signature in inherited classes -> fatal error. I'm sure there are more examples of how PHP 5.2 and newer will enforce a different "spirit" that smells more off a static programming language. Edin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
