I don’t think it’s helpful to compare C#’s BC policies to PHP’s. C# is used today mostly as its architect intended at its founding. PHP, having transitioned from a templating system to a fully-fledged language, is used quite differently.
> On Aug 29, 2019, at 11:50 AM, Chase Peeler <chasepee...@gmail.com> wrote: > >> 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
