Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104329
MIME-Version: 1.0
References: <CAF+90c_wZvdgVbmdHH+7J=CLx-rivDRr4vB3=HXK3K2HSNAqMg@mail.gmail.com>
 <CAEZPtU5G9BABiKJnJgOCrRoaaBW-rxE=PmwWL6w2vgm1P5+-rw@mail.gmail.com>
 <CAFPFaMJsOYbD8JxRK6OupenQKn-fWek=b4xZ+407msm7Kv2Vzw@mail.gmail.com>
 <CAEZPtU71hSzdSk7W7d_A7mbYYFRx0BRGATOdy4CtVX9k0dYwPQ@mail.gmail.com>
 <220843E5-03CD-4E7E-8DB5-1062C24AB8CE@cschneid.com> <CAEZPtU5At4bKVuoF8=WEff4qTCEoo3fiuLn7Dmss=_-UXJs5sQ@mail.gmail.com>
 <1cac1e56-56bd-5995-353b-283cd7c89c7a@gmail.com>
In-Reply-To: <1cac1e56-56bd-5995-353b-283cd7c89c7a@gmail.com>
Date: Sun, 10 Feb 2019 09:34:16 +0700
Message-ID: <CAEZPtU6vp4dAs+5BKmJWLj8E5sV1BALru37bUf4v8fsPcNQHmA@mail.gmail.com>
To: Stas Malyshev <smalyshev@gmail.com>
Cc: Christian Schneider <cschneid@cschneid.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000f04ff805818107c3"
Subject: Re: [PHP-DEV] Don't silence fatal errors
From: pierre.php@gmail.com (Pierre Joye)

--000000000000f04ff805818107c3
Content-Type: text/plain; charset="UTF-8"

HI Stas,

On Sun, Feb 10, 2019, 8:17 AM Stanislav Malyshev <smalyshev@gmail.com wrote:

> Hi!
>
> > My thought that @ mainly relates to another RFC where errors/warning
> > are very inconsistently reported or designed (like forcing one to use
> > @). 8 would be a good candidate to clean that up, like the TypeError
> > RFC.
>
> Cleaning up how PHP does errors would be awesome. After 20+ years of
> organic growth without clear standards in this area, we've got a lot of
> messy stuff happening there. But I don't think it can solve any
> immediate issues

- it's not likely that we'll replace every warning in
> every extension overnight.


You are right, long due. Also 8 is not immediate or overnight.

However I think you are right as well in your other replies. While I wrote
@ free code since years and I rarely see some in modern code, removing it
may bring some BC issues that could delay 8 adoptions.


It'd be nice if we found some model that
> miraculously plugs into existing one and allows to improve things while
> keeping everything working. If we get good new APIs - fine, but we'll
> need @ to work with old APIs for a while.



New APis would be amazing. We need a kind of miracle to agree on these new
APIs but it will be really amazing to have new clear APIs. As far as I
remember we have been there for 6/7 and failed to find a consensus.
Resources and procedural APIs behaviors have survived a few attempts to
kill them. I wish we could introduce some key ones with 8 and not barely
focused in JIT and some basics cleanup :)

By procedural behaviors, I mean all these functions based on the 90s
designed C-like behaviors which are not fit anymore for today needs.

best,
Pierre

--000000000000f04ff805818107c3--