On Thu, Aug 29, 2019 at 10:22 AM Zeev Suraski <z...@php.net> wrote: > On Thu, Aug 29, 2019 at 4:02 PM Aegir Leet via internals < > internals@lists.php.net> wrote: > > > I know what the manual says about notices. But I don't agree with > > interpreting "could happen in the normal course of running a script" as > > "it's perfectly fine if this part of your code triggers a notice > > consistently and every time it goes down this particular code path". > > Rather, I've always interpreted this as "under certain, rare, unforeseen > > circumstances, your code could generate a notice here, probably because > of > > something that is outside of your control". > > > > That's how I've always treated them at least. > > > > And that's entirely within your right to do so - but what the manual says > is accurate. Calling me delusional in my interpretation of it is somewhat > awkward (to put it mildly), I have a pretty good idea of why we added the > different error levels - I wrote much of it myself. > > The whole point of having notices as something that's separate from > warnings is that they have different semantics, and that semantics is > captured very accurately in the manual. They are used to mark issues which > may be problems, but may also be perfectly fine (unlike warnings, which > generally speaking mean that something bad happened, but not bad enough to > halt execution). Notices were meant to help you implement a more strict > style of coding, and they may help you catch certain types of bugs, but you > can have perfectly working, bug-free code that generates notices. > > Regardless of the exact semantics, don't you think a program that generates > > a constant stream of notices is a bit strange? That sounds like something > > everyone would naturally want to avoid. You don't drive your car with the > > check engine light permanently on and say "this is fine", right? > > > Except you can purposely turn off this 'check engine' light, never to see > it again if you choose to. And that it's really not at all similar to > 'check engine', but a lot closer to 'check cleaning fluid', or even 'clean > windshield' (if cars had a dashboard light for that). Even that is not a > good analogy - as folks often actually purposely write code that generates > notices (which would be purposely hidden, either by error_reporting setting > or using @) that is 100% bug-free and working as intended. So no, there's > nothing strange about it if you buy into that approach. If you don't (and > I know you don't) - that's absolutely fine - it's up to you. > > Zeev > I just wanted to bring up a few other points. First, as I think Stanislav has done a good job of pointing out, the flexibility of PHP is one of its greatest features. The nice thing about a flexible and forgiving language is that you can always put additional things in place on top of it to make it more strict and rigid if you want. Once you force a language to be strict and rigid, however, it's much harder, if not impossible, to add back in flexibility.
A lot of my emails on this thread have been focused on the burden to developers caused by the BC break. While I still think that is an important consideration, it distracted me from my initial view which was we shouldn't do this because it's just a bad idea. I understand all of the arguments for enforcing variable initialization. I agree with most of them as well. However, I think there are a myriad of ways that individuals and teams can do that enforcement without forcing it on every single developer whether they want it or not. A lot of comparisons have been made to other languages. I do a lot of work with javascript and I have a good amount of experience with c# as well. I've used many other languages at times (c, c++, java, perl, ruby, etc.) as well. In c#, you don't have to initialize your variables - you have to declare them. Some types, like ints, are automatically initialized to 0 unless explicitly initialized to something else. PHP doesn't require you to declare variables. So, while c# might require "int i; i++;" you can achieve the same thing in PHP with "$i++;" - neither one requires an explicit initialization. A few people have referred to the fact that I have instances of undeclared variables as technical debt. As I said earlier, I've engaged in these discussions because I don't think just calling something technical debt should be justification for a change. The fact that a large number of developers might have technical debt in a certain area should be considered when weighing the pros and cons of a breaking change. That being said, I do NOT consider such code to be technical debt or bad code that needs to be fixed. The only way it becomes either of those if with the implementation of this RFC. It's a bit disingenuous to tell developers they have to make large changes, and when they push back, tell them it's their fault for accruing so much technical debt - when it's the RFC itself that actually causes the technical debt to begin with! *I will no longer engage in conversations on this topic that relate to how you think my company should conduct business or prioritize development. * Finally, since people seem hell bent on turning PHP into a language that operates like all the others, instead of letting it keep its unique qualities that make it great and different, I asked a c# developer I know about how Microsoft deals with breaking changes. Here was his response: "I’ve never heard of a breaking change when new versions of C# are released. There are occasionally breaking changes when upgrading to a new version of .NET, but they always (as far as I’m aware) have a way to prevent the change from breaking anything by adding a parameter the app’s configuration." -- Chase Peeler chasepee...@gmail.com
