Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116364
MIME-Version: 1.0
References: <d204e072-0982-624e-a789-f79af7e99177@gmail.com>
In-Reply-To: <d204e072-0982-624e-a789-f79af7e99177@gmail.com>
Date: Mon, 15 Nov 2021 13:03:28 +0100
Message-ID: <CABdc3Wo2=zRfuSyTZ6K=TxnY3=uRoLPg+LqsS8XsyztyAM4O5g@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000007027fe05d0d29918"
Subject: Re: [PHP-DEV] Finer control of diagnostics (deprecations, notices,
 and warnings)
From: michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Marcin_Brzuchalski?=)

--0000000000007027fe05d0d29918
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Rowan,

pon., 15 lis 2021 o 12:34 Rowan Tommins <rowan.collins@gmail.com>
napisa=C5=82(a):

> Hi all,
>
> Concerns have been raised a few times recently about adding new warnings
> and deprecation notices, particularly:
>
> * That code bases with many instances of a particular pattern see a lot
> of noise when a message is added
> * That library maintainers face pressure to fix deprecations from users
> who don't want to see those messages in their logs
>
> I don't think "stop adding new diagnostics to PHP" is a good solution to
> these problems, and have thought of two ideas which might improve
> things; both need refinement, but I hope can at least act as discussion
> starters.
>
>
> The first idea is directory-level error_reporting configuration.
>
> In principle, this would be very simple: a mechanism (ini setting or
> function) that lets a user specify a different error_reporting level for
> all code compiled from a particular directory. The most common use I
> foresee is reducing reporting in third-party libraries, e.g.
>
> error_reporting=3DE_ALL
> error_reporting[*/vendor/*]=3DE_ERROR+E_WARNING
>

IMO this screams for comments regarding
modules/packages/assemblies however called
where error_reporting could be controlled by vendors.
Personally, I think that given feature users would add whole vendor
directory,
since the vendor/package directory is not fixed,
may change - which in essence may go out of control and silently invoke a
waterfall of unexpected errors.


> This would hopefully reduce pressure on maintainers to fix deprecation
> notices as soon as they appear, because they would no longer be
> cluttering the user's logs.
>
>
> The second idea is diagnostic codes or categories.
>
> This is more complicated, because it requires classifying all existing
> diagnostics to add extra information, but would allow users to act
> differently on specific messages. They might suppress them, downgrade
> Warnings to Notices, or even upgrade Notices to Warnings - as they might
> with rules in an IDE or Static Analysis tool.
>
> As an extension, the @ operator could be enhanced to suppress a specific
> diagnostic, so that the following would give an "undefined variable"
> warning, but be silent about the file not existing:
>
> @{FILE_NOT_FOUND}fopen($undefinedVariable, 'r');
>

This proposal allows to silence errors in certain statements but instead of
extending silence operator
personally, I'd prefer to enable statement-level attributes and shape them
in an opt-in manner.
Instead of proposing new syntax backward incompatible like this:

$fp =3D @{FILE_NOT_FOUND}fopen($undefinedVariable, 'r');

introduce statement level attributes which can be backward compatible when
in one line

$fp =3D
#[SupressErrors(E_WARNING)]
fopen($undefinedVariable, 'r');

What do you think?

Cheers,
Micha=C5=82 Marcin Brzuchalski

--0000000000007027fe05d0d29918--