Re: [PHP-DEV] Changing fundamental language behaviors

This is only part of a thread. view whole thread
  106968
September 12, 2019 15:01 j.boggiano@seld.be (Jordi Boggiano)
On 12/09/2019 16:44, Zeev Suraski wrote:
> Similarly - adding typed variables - is certainly a future option. Changing > PHP to require typed variables (without opting in) - is well outside of the > internals@ mandate. > > > > For areas like that - our options are either doing nothing, or providing > opt-in mechanisms to cater to stricter-loving audiences. I'm all for the > 2nd option, but there is no 3rd.
While I am not sure your tone will be well received by your target audience, I just wanted to say I tend to agree. Breaking BC here does not seem to bring much. If there are cases where enforcing strictness might allow better JIT for example, then I could see the case being made. But simply turning working code into fatally failing code isn't progress. I know I have a bunch of old stuff running which tends to litter the error logs with notices, and I don't have time to go fix them so I ignore because it's fine and it works. For new projects, what I do, and what I am pretty sure 99% of the "strict camp" does is essentially boiling down to:     set_error_handler(function () { throw new \RuntimeException(); }); That's our global strictness flag right there. It's been available for ages. I don't see why we need to take something away from others to make such an easy workaround a little less needed. Especially as I don't imagine we will drop the error handlers. I sure will keep mine around to keep failing warnings etc as hard fatals. So what do we gain exactly? Best, Jordi -- Jordi Boggiano @seldaek - https://seld.be
  106973
September 12, 2019 15:11 chasepeeler@gmail.com (Chase Peeler)
On Thu, Sep 12, 2019 at 11:01 AM Jordi Boggiano boggiano@seld.be> wrote:

> On 12/09/2019 16:44, Zeev Suraski wrote: > > Similarly - adding typed variables - is certainly a future option. > Changing > > PHP to require typed variables (without opting in) - is well outside of > the > > internals@ mandate. > > > > > > > > For areas like that - our options are either doing nothing, or providing > > opt-in mechanisms to cater to stricter-loving audiences. I'm all for the > > 2nd option, but there is no 3rd. > > > While I am not sure your tone will be well received by your target > audience, I just wanted to say I tend to agree. > > My thoughts as well.
> Breaking BC here does not seem to bring much. If there are cases where > enforcing strictness might allow better JIT for example, then I could > see the case being made. But simply turning working code into fatally > failing code isn't progress. > > Yes!
> I know I have a bunch of old stuff running which tends to litter the > error logs with notices, and I don't have time to go fix them so I > ignore because it's fine and it works. > > Can't make that argument. Be prepared to be told how easy it should be for
you to fix it, or, how it's technical debt (ignoring the fact that it's not technical debt currently, since there is nothing wrong with what was written) and you're just making things worse by not taking care of it.
> For new projects, what I do, and what I am pretty sure 99% of the > "strict camp" does is essentially boiling down to: > > set_error_handler(function () { throw new \RuntimeException(); }); > > That's our global strictness flag right there. It's been available for > ages. I don't see why we need to take something away from others to make > such an easy workaround a little less needed. Especially as I don't > imagine we will drop the error handlers. I sure will keep mine around to > keep failing warnings etc as hard fatals. > > So what do we gain exactly? > > That's the argument I've been making all along. There are so many ways to
accomplish what has been proposed without forcing it on those that don't want it. It's not required in order to add new features to the language. It doesn't make the language perform better, either. It's also not taking away something that is definitely a negative feature. It's taking away something that many view as a positive feature of the language. If there was no way to achieve the intended results without making the change, I might be more sympathetic to making it. But there is. Whether it's an error handler like you mentioned above, stricter code reviews, public shaming for anyone that doesn't initialize their variables, or any of the myriad of other options.
> Best, > Jordi > > -- > > Jordi Boggiano > @seldaek - https://seld.be > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
-- Chase Peeler chasepeeler@gmail.com