Hi Rowan,
pon., 15 lis 2021 o 12:34 Rowan Tommins <rowan.coll...@gmail.com>
napisał(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=E_ALL
> error_reporting[*/vendor/*]=E_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 = @{FILE_NOT_FOUND}fopen($undefinedVariable, 'r');
introduce statement level attributes which can be backward compatible when
in one line
$fp =
#[SupressErrors(E_WARNING)]
fopen($undefinedVariable, 'r');
What do you think?
Cheers,
Michał Marcin Brzuchalski
