Am 27.01.2022 um 05:17 schrieb Mark Randall <marand...@php.net>: > It is my firm believe that a language such as PHP should not be dependent on > static analysers to protect users against engine-level problems that may > occur during runtime.
My issue with this is that while it seems to work towards the goal of "fail fast" it does not completely fulfill its promise. What do you gain by making undefined variables an error? You force developers to sprinkle their code with variable initializations where they might be sure that the well-defined behavior of undefined variables is fine in their code. Why is that a problem? One of the burdens of early statically typed languages was that you had to declare everything in detail. It was with the advent of type inference that some of the typing overhead could be reduced and a balance between safety and readability through DRY was reached. Forcing to initialize everything moves PHP against DRY while the safety gained by aborting the program is debatable, even though better approaches (like static analysis) are available now. To me it's about using the right tool for the right job. > However, internals is not responsible for getting people to use a static > analyser, we are responsible for the behaviour of the engine, and right now > the engine is, I think, too lax in this regard. My counterpoint would be that there are other topics where internals decided that something is better handled in user-land than on the engine level. You could say that the engine can provide an additional layer but I could counter that it discourages people from using a static analyzer because they have a (possibly false) sense of security. > That you're manually patching PHP to change official behaviour (which was > passed by RFC) puts your individual use case well outside of what should be > considered when voting. Let me explain: First we were suppressing some warnings in an error_handler (and we are not the only ones doing it) and the decision to go one step further was taken because we didn't want to pay the performance penalty after collecting enough experience with not having this warning. While you may disagree with that approach it is still an indication that there are different views on this, which should be considered. The loser of a vote should not be completely ignored ;-) Anyway, I think we've covered the two sides of the story quite well now, I'll refrain from making this thread longer than necessary. Regards, - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
