Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116368
Message-ID: <831911b1-69ea-f55e-a032-4a9b5865fe5f@gmail.com>
Date: Mon, 15 Nov 2021 13:17:55 +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>
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>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Finer control of diagnostics (deprecations, notices,
 and warnings)
From: rowan.collins@gmail.com (Rowan Tommins)

On 15/11/2021 12:03, Michał Marcin Brzuchalski wrote:
> 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.


I don't understand your concern; possibly you have misunderstood my 
suggestion?

I'm saying that a user who wants to see if they are using deprecated 
features in their own code would want to turn on E_DEPRECATED in their 
main error_reporting, but turn it OFF for all third-party code. Most of 
the time, deprecation notices in third-party code are not useful to 
users: they are not responsible for fixing them in advance, and when 
actually switching major PHP version, they may have to switch to a 
different major release of the library before testing anyway.

Regards,

-- 
Rowan Tommins
[IMSoP]