Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106973
MIME-Version: 1.0
References: <076701d56978$86020910$92061b30$@php.net> <783971db-7835-3fc5-60a3-ca25c38cdc3e@seld.be>
In-Reply-To: <783971db-7835-3fc5-60a3-ca25c38cdc3e@seld.be>
Date: Thu, 12 Sep 2019 11:11:36 -0400
Message-ID: <CAPKYkKwarWaMp2vHo-cEmsfdGr0Z7W6GRsVDyJ919wJxhNSwbg@mail.gmail.com>
To: Jordi Boggiano <j.boggiano@seld.be>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000072e72505925c8e31"
Subject: Re: [PHP-DEV] Changing fundamental language behaviors
From: chasepeeler@gmail.com (Chase Peeler)

--00000000000072e72505925c8e31
Content-Type: text/plain; charset="UTF-8"

On Thu, Sep 12, 2019 at 11:01 AM Jordi Boggiano <j.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

--00000000000072e72505925c8e31--