On Thu, Sep 12, 2019 at 1:39 PM Olumide Samson <oludons...@gmail.com> wrote:
> > > On Thu, Sep 12, 2019 at 6:22 PM Chase Peeler <chasepee...@gmail.com> > wrote: > >> On Thu, Sep 12, 2019 at 1:05 PM Matthew Brown <matthewmatt...@gmail.com> >> wrote: >> >> > that don't fundamentally change the language >> > >> > >> > There's clearly a big disagreement about whether this is a fundamental >> > change or not. >> > >> > Preventing something that the entire field of software engineering >> frowns >> > upon (and that most PHP developers avoid like the plague) doesn't seem >> like >> > a *fundamental* change. >> > >> > >> I would argue that this is exactly such a change. The flexibility of PHP >> has often been touted as a feature and something that sets it apart. >> Whether that's good or bad is, frankly, irrelevant. There are valid >> reasons >> for not always initializing variables or array keys. > > The major valid reason i see is creating a bolierplate or being lazy to > initialize the variable with even null or similar null-type depending on > its context. > > It might be a bad reason in your opinion, but others view it as perfectly >> acceptable. > > Who are those "others"? > I think he(me included) is also one of those "others" that view it as bad > programming style... > > For 20 years people have developed code based on that feature. It was never >> considered an error, and often not even considered bad practice. > > It was considered an error, that's why you were been warned or given > notice that "Hey dude, you're writing a bad code here @ line 1427(l4zy) of > already-problematic-file.php" and only if we want to remove Notice,Warning > or Error in the language. > No, as discussed previously, notices were never meant to signify a definite issue. They are "Hey, this might be an issue, it might not, maybe check it out if you want?" thing. This RFC is proposing that we actually halt execution of programs that currently work perfectly fine and run exactly as they were intended to. > To suddenly define it as such is the exact definition of a fundamental >> change >> to the language itself. >> > Fundamental is always "fundamental", i think there's no good definition > for it in this context, so leave fundamental changes out of this discussion > as something totally bad been cleaned up is a fundamental change and > something new but not used right and changed to be used right is also > fundamental... > I would said fundamental is any behavior that is expected and intended. At this point, the fact that you don't have to initialize your variables is an intended feature of the language. That means people should be able to depend on such a feature existing. The fact that you don't like it shouldn't be a justification for breaking that, especially when nothing is stopping you from being as strict as you want with your own code. You can also hold any third party libraries that you use to the same standard if you want. > >> What if Java suddenly said that all properties are suddenly private, and >> can only be accessed through getter/setter methods? The fact that you >> should make properties private and use such methods is a practice that was >> drilled into me from day one. Would that justify making such a change, >> though? >> >> I'm not sure how this relates, i think Java would let you see the good or > bad, it's up to you to see or not from their view, let the majority move > forward and don't be a stopping stone in moving this language past the 1993 > bondage(needle-haystack, inconsistent naming and many issues we couldn't > count)... > It relates because right now, it's a feature of Java that you can make properties public and then modify those directly from outside the class. Since it's an intended feature, a lot of people have written code that directly accesses public properties.You could argue the only use-case for doing so is that they are too lazy to write the getter/setter methods, but that doesn't change the fact that such code exists and is not an error or even a misuse of a current feature. -- Chase Peeler chasepee...@gmail.com
