pon., 15 lis 2021 o 13:03 Michał Marcin Brzuchalski <
michal.brzuchal...@gmail.com> napisał(a):
> 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');
>
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,
