Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:112840 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 91817 invoked from network); 11 Jan 2021 02:32:43 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 11 Jan 2021 02:32:43 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id C9EF91804AA for ; Sun, 10 Jan 2021 18:10:16 -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.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_PASS,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sun, 10 Jan 2021 18:10:15 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 6A3045C00F4 for ; Sun, 10 Jan 2021 21:10:15 -0500 (EST) Received: from imap26 ([10.202.2.76]) by compute4.internal (MEProxy); Sun, 10 Jan 2021 21:10:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=pm44Nk 1yxZE2DHty874umYsSE7FSsb1um31lPNGrx28=; b=NhJWbB4pNo6TxuR5Y4Olzr gtAMOUHpHq/p3825urKYbXivP2wlq/0W7IjgKNuzZ9e7wRLpddqi25jvBtm1eb00 1UcTQRRfvu04vAiEH2UiDB7dpgFIq+1uPDHcreQo0osPwqC/iNc4/cTeew9cIriu FfyIob96zh8I/yGFKXjRyMb1nnjRkYcbYqFOnjF8aekGemVgTNOID4ygt6jYOZnt Gaxa871Br56OPPydF78kD6LVfe/2ZDsHZq9iVT2GnfeY5sHlbUP1dJqK8jAyi5H2 3G1ietxuWjsnVz8U7rVU5dXOC66rKS5+XSo3ue9MKFnIwwqdhON0yTD3c37nUaQA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdehtddggedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdfnrghr rhihucfirghrfhhivghlugdfuceolhgrrhhrhiesghgrrhhfihgvlhguthgvtghhrdgtoh hmqeenucggtffrrghtthgvrhhnpeeglefgkeduiedvvdetffeujefftdfhjeeiveehgfff keduveektddvledvvdfffeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpehlrghrrhihsehgrghrfhhivghlughtvggthhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id BA3CC14200A2; Sun, 10 Jan 2021 21:10:14 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-45-g4839256-fm-20210104.001-g48392560 Mime-Version: 1.0 Message-ID: In-Reply-To: References: Date: Sun, 10 Jan 2021 20:09:54 -0600 To: "php internals" Content-Type: text/plain Subject: Re: [PHP-DEV] Re: "TryX" idom for Enumerations From: larry@garfieldtech.com ("Larry Garfield") On Sun, Jan 10, 2021, at 4:40 PM, Mark Randall wrote: > On 10/01/2021 21:27, Larry Garfield wrote: > > The "a method that begins with try is nullable, so watch out" idiom is present in C# and Rust, but to my knowledge has never existed in PHP. That doesn't make it bad; it actually combines quite well with the null coalesce operator to allow for default values, making a valueOrDefault() method unnecessary. > > I get the advantages of returning null, in particular WRT the null > coalescing operator. > > However, when I see 'try' I instictively think 'exceptions' i.e. > try/catch when the reality is it's the opposite and it would be the > non-try functions which throw. > > But it makes sense for those to throw. That was my initial response as well, and my main concern. To a PHP developer, the terminology seems backwards. But it's not like we haven't adopted idioms and syntax from other languages before. > However if you will permit me a tangent... > > There is an alternative, of sorts. Something I tried investigating when > I first started looking into PHP-SRC, but lack the skill and knowledge > to implement myself. > > A shorthand try / catch of something like the form: > > ( ResultExpr, ...) > > At which point tryFrom becomes: > > $order = attempt(SortOrder::tryFrom($input), ValueError => SortOrder::Asc); > > Which would be the equivilent of: > > function attempt(callable $try, array $map): mixed { > try { > return $try(); > } > catch ($e) { > foreach ($map as $class => $expr) { > if (is_subclass_of($e, $class, true)) { > return $expr(); > } > } > > throw $e; > } > } > > Or just allow a mixed value to be given without a mapping for catching > Throwable. > > If added as a language construct, except each expr and $try itself would > be parsed closure at language construct level to avoid needing to fn() > them all e.g. > > $foo = attempt(fn() => SortOrder::tryFrom($input), [ ValueError => fn() > => null ]); > > Just a thought, perhaps a cleaner solution to a wider problem. A try / > catch combined with a match. > > It avoids the need for two methods, just provide the one that throws and > use shorthand to assign a null if it throws. > > Mark Randall The main issue I see is that creating an exception is quite expensive. (Or it was the last time I bothered benchmarking it, which admittedly has been a while.) So even if you had some built in "catch and match" pseudo-function, you're still paying the cost of the exception, which is not cheap. catch-and-match is an interesting idiom, but as you say it's somewhat tangential to the question at hand. --Larry Garfield