Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116365
MIME-Version: 1.0
References: <d204e072-0982-624e-a789-f79af7e99177@gmail.com> <CABdc3Wo2=zRfuSyTZ6K=TxnY3=uRoLPg+LqsS8XsyztyAM4O5g@mail.gmail.com>
In-Reply-To: <CABdc3Wo2=zRfuSyTZ6K=TxnY3=uRoLPg+LqsS8XsyztyAM4O5g@mail.gmail.com>
Date: Mon, 15 Nov 2021 13:06:28 +0100
Message-ID: <CABdc3WqfouKw+RVdYdz5hKiVgUv2-uSN-S0ezj=_X3WNpP3p1w@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000029f3e005d0d2a459"
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?=)

--00000000000029f3e005d0d2a459
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

pon., 15 lis 2021 o 13:03 Micha=C5=82 Marcin Brzuchalski <
michal.brzuchalski@gmail.com> napisa=C5=82(a):

> 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 the=
m
> 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 whe=
n
> in one line
>
> $fp =3D
> #[SupressErrors(E_WARNING)]
> fopen($undefinedVariable, 'r');
>

My apologies this won't work for 8.0 and 8.1 since there are no
statement-level
attributes and the online attribute as a comment hack works only for <8.0
versions.

Regards,

--00000000000029f3e005d0d2a459--