Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113383 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 87326 invoked from network); 4 Mar 2021 17:55:36 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 4 Mar 2021 17:55:36 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 7E9421804D0 for ; Thu, 4 Mar 2021 09:46:24 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-ej1-f47.google.com (mail-ej1-f47.google.com [209.85.218.47]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 4 Mar 2021 09:46:24 -0800 (PST) Received: by mail-ej1-f47.google.com with SMTP id hs11so51085773ejc.1 for ; Thu, 04 Mar 2021 09:46:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jgdnvv6PfFOVWeRgLCPPX8Y7wjo/l64/ODfIeUIpMCg=; b=BvbIm4nbkxowrMa+uPb69P+ghB473aZZQZT+bpGNNYns6O4yTVTHYmADAEbQpzWZ6/ 5PZoPCFWlyxwbre6DoMNCeWuqyunN1qmtUhun37e4cN9/j5EC4nngTlSUZ49z53K29l0 PpvQtjd9MqkKfFMdnN4u2iPbdE3PezAHXIFZk91GV5CyLOspTXrv3ku5UPmlgN3a561+ 3SwncQAGNLZpQp+KUY5c7row4+frvaOlG6yghypb8awJdOJoTqq+wpLR0JVb/ypRCSHH OMvJvJsR1vODOLSUeZ4CA6NJoScyD72tBdcclPEHaqvNNDRgupvQHdgY3MIxVAGUWHWn EhmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jgdnvv6PfFOVWeRgLCPPX8Y7wjo/l64/ODfIeUIpMCg=; b=RLlFqK4fU3P8QS00QINT5LbTV2ktUwBa9PtaIIIr6kWWn2l4cq/s4ONMbQdEVomM8k zX3sGxnu9II12TOuV39XVr+naap2Y7GxrFbSivBwsdoAQhJq606jpFkIiR18viPQfKvu jsJmRsFrgZsrs1bs7S1+ErL2FV+16ckqXA/BVfAcLvNqLon47FpG+EoK0ggQQgyBJKOT Wc33154f5sIIjFSzrlWyMApfGQUEYz7q+XPhLIJ9wIQvZ+zJyTIA/Mfm06cgb81MMYTF NgTpv0oR0if38NDMK1ZHKKLD/lqD5yypwoB6TPv5E2onpAXteAChJxU6DEN5fBPV/8Su Od3g== X-Gm-Message-State: AOAM532nPXvW2YjPlr3xAPNuflLAIr3BpGw92i1IcrkqLMs7ZARwbcyv wqjGnf9ab8hRp+qziIj/lSS/GjLolTpPOgZpXtHxptdXkpo= X-Google-Smtp-Source: ABdhPJx/sXIveqDuvgZsEZpd2WRZr7rqhBqmFCgs7v9I7M44qibsXUeFs1okb1d+vdlRdmHam0dkYZGHj8gf5ggWlP8= X-Received: by 2002:a17:906:a51:: with SMTP id x17mr5624517ejf.25.1614879981782; Thu, 04 Mar 2021 09:46:21 -0800 (PST) MIME-Version: 1.0 References: <2dcc41aa-6518-baf1-5548-de0c41e0a8f3@allenjb.me.uk> In-Reply-To: <2dcc41aa-6518-baf1-5548-de0c41e0a8f3@allenjb.me.uk> Date: Thu, 4 Mar 2021 17:46:10 +0000 Message-ID: To: AllenJB Cc: PHP internals Content-Type: multipart/alternative; boundary="000000000000ab4abc05bcb98b23" Subject: Re: [PHP-DEV] [RFC] Extend error control operator to suppress exceptions From: george.banyard@gmail.com ("G. P. B.") --000000000000ab4abc05bcb98b23 Content-Type: text/plain; charset="UTF-8" On Thu, 4 Mar 2021 at 16:06, AllenJB wrote: > > 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). > Maybe, or maybe redesigning an API and rewriting code is suboptimal. But maybe it's also the fact that the documentation doesn't signal the alternatives enough due to lack of documentation maintainers which apparently you don't think it is an issue but I address this below. But in any ways there are over 2500 error/warning/notices in bundled extensions, it is *not* just an I/O issue. But the I/O functions do have somewhat of an alternative which has failed, reasons for that are up to debate. > 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) > The docs are already arranged in "topic oriented" way, look at the function reference page: https://www.php.net/manual/en/funcref.php > 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? > The matter of fact is that at this time there is mainly 1 person which solely works on the documentation, and that is Christoph M. Becker (aka cmb) with some occasional contribution from other individuals (me included) even with an issue tracker we are far from having all the changes for PHP 8 documented, and even some PHP 7 behaviour is not documented. So documentation burden is a thing, should it prevent feature additions to the langage? Obviously not, and we mostly deal with this "just" fine as for the docs of the major PHP 8 features were written by their respective RFC authors. A big reason why there was no documentation for false return in the signature is that until recently we did *not* have the capability to display union types via the Doc render (PhD), this is now being corrected but is a tedious job of syncing the docs from the officials stubs to also sync named arguments. > 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)) > It is for certain easier to review doc patches now that it's on git with a mirror on GitHub, and we do get contributions but no where near the amount needed to tackle all of the doc bugs, and other issues. > 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. > I have at this time no intention of bringing forwards such a proposal, and I don't see how adding a way of handling errors differently would reverse the trend of moving things to Throwables, the point of such an alternative error handling mechanisms is to make dealing with Throwables easiers in situations where they might be more expects, such in low level I/O code. > 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. > Until the whole namespace debacle is sorted in some shape or form, this idea is dead in the water. Moreover, I'm having trouble understanding how it would interact with a call to a function which doesn't exist in that fallback namespace such a strlen(), would it first look in the fallback namespace (potentially multiple fallbacks) before looking back into the global one or? Best, George P. Banyard --000000000000ab4abc05bcb98b23--