Javascript has treated undefined variables as a catchable exceptions since (I think?) forever. Perl is the only other language I know that allows them.
I've written code in a lot of different languages. Many of those languages (most notably Standard ML) forced me to think about how exactly data flowed through my program. PHP, on the other hand, doesn't demand anything like as much work. This means its developers often don't improve much either, which ultimately this harms the language's reputation as former PHP developers discover their bad habits don't translate well to other languages. With this change we can make it harder for people to write bad code, which I think will result in existing PHP users becoming better developers. On Wed, 28 Aug 2019 at 14:32, Zeev Suraski <z...@php.net> wrote: > > > On Wed, Aug 28, 2019 at 8:20 PM Matthew Brown <matthewmatt...@gmail.com> > wrote: > >> We log 1 in every 1000 notices, and yes - being notice-free is a goal – >> though not one with any particular timeline at the moment, because we can >> just ignore the problem. I look forward to not being able to ignore the >> problem. > > > When was this goal set? Was there effort that went into it? > > My point is this: > > In a codebase where being notice-free isn't a goal - and/or where code > patterns that rely on the documented behavior of how PHP variables are > initialized as well as behave in read scenarios (with or without the > silence operator) - I think you're going to find a lot of such instances, > probably more so than in a company that made an informed decision to not > allow it and gradually work to remove existing code that uses it. For > many, this is not considered technical debt - but rather - using the > language *as intended*. Using the language in a way that is sanctioned and > considered valid - alongside other ways which are also considered valid > (e.g. a notice-free codebase). > > While I understand what you're saying when you say that you look forward > to not being able to ignore the problem, it sounds like a fairly weak > argument for forcing everyone else - many of whom don't consider this to be > a problem at all - to change their code. Instead, if this bothers you, > make an informed decision to change - there's enough tooling to do that > today with reasonable effort. Or support the ability to flip a switch that > will granularly force you to fix these particular issues. Forcing all > users to work in a certain way, because some of the users who want to work > that way can't bring themselves to do it - doesn't sound very sensible IMHO. > > I was hoping that the glaring obviousness of how other languages tackled > similar issues (Perl, JS) would go a longer way. It should. > > Zeev >
