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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
