Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113381
To: "G. P. B." <george.banyard@gmail.com>,
 PHP internals <internals@lists.php.net>
References: <CAFPFaMLhUtvygtkgWvDRYZvCc8sFNtVDiUEmAHjuXK+H=aFHbA@mail.gmail.com>
Message-ID: <2dcc41aa-6518-baf1-5548-de0c41e0a8f3@allenjb.me.uk>
Date: Thu, 4 Mar 2021 16:06:33 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.8.0
MIME-Version: 1.0
In-Reply-To: <CAFPFaMLhUtvygtkgWvDRYZvCc8sFNtVDiUEmAHjuXK+H=aFHbA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] [RFC] Extend error control operator to suppress
 exceptions
From: php.lists@allenjb.me.uk (AllenJB)


On 04/03/2021 14:08, G. P. B. wrote:
> Hello internals,
>
> This new RFC which I'm proposing is to extend the capability of the error
> control operator @ to not just suppress diagnostic messages but also
> exceptions.
> It can currently be found on GitHub: [1]
> https://github.com/Girgias/error-control-operator-exceptions-rfc
>
> The main motivation for this is to provide a path to migrate in a backwards
> compatible manner away from diagnostics such as E_WARNING to the use of
> exceptions without breaking 99% of PHP code which has been written in the
> last 25years.
>
> This proposal on it's own would not be sufficient to trigger such a change
> for extensions but in combination with another proposal to introduce a
> `throw_on_error` declare [2] it could provide a bridge for a gradual
> transition to the use of more exceptions internally.
>
> Although I'm not thrilled with the idea of shoving more functionality into
> @ I don't see any other way, and thus I think it a necessary evil to
> improve the long term health of the PHP project.
>
> Feedback on this RFC and different ideas on how to tackle this topic are
> highly appreciated and welcomed.
>
> Best regards,
>
> George P. Banyard
>
> [1] https://github.com/Girgias/error-control-operator-exceptions-rfc
> [2] Draft RFC for throw_on_error declare
> https://github.com/Girgias/php-rfc-throw-on-error-declare


 > as the I/O API has been revamped within the SPL extension but the 
usage of the traditional I/O functions remains the de facto standard 
within the community.

I don't think that this is really an argument for anything. The SPL 
options aren't obvious - I would wager that many, most even, PHP 
developers barely even know SPL exists. The SPL options aren't pushed 
anywhere in the manual that I'm aware of (for example, the manual page 
for dir() doesn't even mention FilesystemIterator / DirecrtoryIterator 
in any way).

Many developers are already using Safe and similar libraries to get 
"standard library but with exceptions". If this was available in core 
and at least prominently mentioned, if not recommended in the manual 
(could we have a "note box" that's not quite a deprecation notice, but a 
"we strongly urge you to consider this method" in a similar fashion, if 
we don't already?)

If the manual did a similarly better job of recommending SPL ways of 
doing things, I'm sure they'd get used more too.

Would it make sense in some areas such as file operations to have more 
"topic oriented" documentation than the current pure function / class 
listing methodology the manual currently uses? (This might make it 
easier to point out alternatives or make recommendations)


On a related note I dislike "documentation burden" as an argument 
against improvements. I obviously understand "open source, volunteers, 
translations, etc" but I've heard this a few times now as an argument 
against fixing various issues (another example is that many functions in 
the manual document that they can return false, but there's absolutely 
no explanation as to when this can occur except a single paragraph that 
lives on its own page that nobody is ever likely to find if they don't 
already know it exists and you can't tell which functions it actually 
applies to even if you do). Obviously the project doesn't, but if you 
followed this for everything (to the extreme), you'd never introduce any 
new functionality because it would mean adding more documentation pages. 
If this is an issue, does the project need to consider if there are 
better ways to handle documentation?

Are there things the project could implement to improve documentation 
contributions and recruit more translators (something along the lines of 
"bug days" or "Season of Docs"; this might be easier to implement now 
that the docs are in Git(Hub))


With regards to the suggested implementations, I would prefer the 
improved library with exceptions option. I wouldn't like to see yet 
another method of error handling introduced to the standard library 
(such as the Go 2 returns method) - it already has too many. Things have 
been moving in a good direction recently with everything moving toward 
Throwables. I think reversing that trend is a mistake.


Potentially crazy thought: Running with the "improved standard library" 
idea, could this be made easier for developers to use by implementing a 
"use fallback namespace" statement. While PHP currently falls back to 
root / namespace, if the new standard library were - purely for example, 
I'm sure others can come up with a better name - under the namespace 
"/PHP/standard/", developers could add "use fallback namespace 
/PHP/standard/;" to the top of their scripts along with the other use 
statements, and PHP would then try that namespace before falling back 
further to / when encountering undefined classes.