Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:114726 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 57034 invoked from network); 4 Jun 2021 06:17:52 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 4 Jun 2021 06:17:52 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 2322D1804D8 for ; Thu, 3 Jun 2021 23:31:34 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_05,SPF_HELO_NONE, SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from darkcity.gna.ch (darkcity.gna.ch [195.49.47.11]) (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, 3 Jun 2021 23:31:33 -0700 (PDT) Received: from smtpclient.apple (unknown [IPv6:2a02:1205:502d:fa80:a54d:7a45:a7f5:9853]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by darkcity.gna.ch (Postfix) with ESMTPSA id 3354E150E927 for ; Fri, 4 Jun 2021 08:31:30 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Fri, 4 Jun 2021 08:31:30 +0200 References: <6D61A2FD-DC80-43A5-81C2-FB19F9CB5078@dafert.at> To: PHP internals In-Reply-To: Message-ID: <20B8DCDF-B023-43E4-8038-745538915D23@cschneid.com> X-Mailer: Apple Mail (2.3654.100.0.2.22) Subject: Re: [PHP-DEV] Policy for procedural style in new additions From: cschneid@cschneid.com (Christian Schneider) Am 03.06.2021 um 22:47 schrieb Kamil Tekiela :I = love this idea. We should definitely make it official that procedural > style API is unfavourable and should not be added to new classes. > On top of that, I would be in favor of deprecating all existing = procedural > APIs. > - It's making it more difficult to maintain code in two variants > - It's making it difficult to maintain documentation > - It's confusing for users > - Procedural API is usually much more verbose than OO style > - The return values often do not match While I understand your points and especially see the benefit for = maintainers, I'm not a fan of make-everything-OO-with-exceptions. This leads to more exceptions creeping into otherwise exception-free = code. I assume that some people don't see a problem with that but it can = end up using exceptions for flow control which is frowned upon even by = some exception enthusiasts. As soon as you start mixing ifs and exceptions it tends to get messy = because you might even end up converting ifs to exceptions like try { $date =3D new DateTime($datestring); if ($limit > $maxlimit) throw new Exception(...); ... } catch (Exception $e) {} as opposed to if ($date =3D date_create($datestring) and $limit <=3D = $maxlimit) ... I'm fine with new OO style APIs not providing a procedural equivalent = but I'm wary about deprecating/removing existing ones. Final remark: I think neither procedural nor OO style is the right = choice for everything. I believe it should be decided individually. - Chris