Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116363
Message-ID: <d204e072-0982-624e-a789-f79af7e99177@gmail.com>
Date: Mon, 15 Nov 2021 11:34:09 +0000
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.3.0
Content-Language: en-GB
To: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Finer control of diagnostics (deprecations, notices, and warnings)
From: rowan.collins@gmail.com (Rowan Tommins)

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=E_ALL
error_reporting[*/vendor/*]=E_ERROR+E_WARNING

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');


Regards,

-- 
Rowan Tommins
[IMSoP]