Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:111023 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 21281 invoked from network); 15 Jul 2020 16:39:32 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 15 Jul 2020 16:39:32 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 240AB180548 for ; Wed, 15 Jul 2020 08:32:15 -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=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H4,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 wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (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 ; Wed, 15 Jul 2020 08:32:14 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 320ECB4C for ; Wed, 15 Jul 2020 11:32:13 -0400 (EDT) Received: from imap26 ([10.202.2.76]) by compute7.internal (MEProxy); Wed, 15 Jul 2020 11:32:13 -0400 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=fm3; bh=F6ayzu +xAC7IIWP7sxgT9Y7Z1EAy8ZGHBISxJRfOHL8=; b=mch0FBQGGar1YR76+3fn/y J4jqqzsqnxVOQ74KwJK8mapGDHsUAqouxMFcf9lgkHbF7MH+m5mtT+dbuX87JjsY j0A8EnAgOu+Nm7c7DocDZ2yP254eZRXlJ0B1m6/Nkzj0xloNzDNaAFi/s9RFhbXx 3RyxejPolIIB00LeBj1Eb6LAQTgb+eDYRXx82OSloVwHtoqTSEdr6Zgi9Ghgao6G VkxayW0H8TVDljLPe2xbii2aNG/euIWTuUGQ/Mq/gSPUVVEKUhla7fDIhM87lrXs L/X9PM/cdNj2PqhjeTfro04ZKeSlm+5gliCLC9APUJF084hjAEZK01MZpgaLi6Xg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrfedvgdelhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfnfgrrhhr hicuifgrrhhfihgvlhgufdcuoehlrghrrhihsehgrghrfhhivghlughtvggthhdrtghomh eqnecuggftrfgrthhtvghrnhepgeelgfekudeivddvteffueejffdthfejieevhefgffek udevkedtvdelvddvffefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomheplhgrrhhrhiesghgrrhhfihgvlhguthgvtghhrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1370314200A2; Wed, 15 Jul 2020 11:32:12 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-613-g8a73ad6-fm-20200709.001-g8a73ad6e Mime-Version: 1.0 Message-ID: In-Reply-To: References: <21C5073D-3F39-49DA-8686-E027AE780793@joshbruce.dev> Date: Wed, 15 Jul 2020 10:31:50 -0500 To: "php internals" Content-Type: text/plain Subject: Re: [PHP-DEV] [RFC][Discussion] Objects can be declared falsifiable From: larry@garfieldtech.com ("Larry Garfield") On Wed, Jul 15, 2020, at 9:24 AM, David Rodrigues wrote: > I really appreciate any effort that can make PHP a more powerful language. > However, for this item, I believe it will generate much greater cognitive > complexity for new users (and I hate to assume that this is a problem, but > we have to remember our roots). > > Why, for now a variable $x will be truth, since it is an instance of an > object, now it could be false, because it implements __toBool() and > Falsiable interface in a "magic" way, making everything very confusing if > the user is not aware of each class that he is instantiating (or even > receiving from other places without much condition to know precisely what > it is). > > For this type of situation, I still prefer the introduction of clearer > methods that suggest the validation of your own properties, in order to > make it much more flexible than simply returning a single "general" boolean > by-instance. For example: isValid(). > > if ($entity?->isAdministrator()) { /** Entity is an administrator. */ } > else if ($entity?->isModerator()) { /** Entity is a moderator. */ } > else if ($entity) { /** Entity should be an user or similar. */ } > else { /** Entity is not defined. */ } > > On the other hand, the implicity (bool) cast working together with > __toBool() is a good one, but I think that it is being discussed in another > topic. > > > Atenciosamente, > David Rodrigues This really isn't about using the variable that comes back. For that, sure, nullsafe is helpful. It's about the type of the return value and allowing a class to have an "empty"/"false"/"nope" version. $u = $repo->getUser($id); What happens if the user isn't found in the DB? Options today are: 1) return null, which is a non-type, and thus you need to make the return type ?User or User|null, which means the caller *must* always check it's nullness. 2) return false, which is just wrong on numerous levels and you should never do that. 3) Throw an exception, which is expensive in PHP. Now you're using an exception for flow control, which is generally disapproved of. Allowing an object to falsify itself is a 4th, more type-safe option. It lets you return an object that both fails a boolean check (like null) but also has default values in it for the base case. A user object likely wouldn't use that, but a value object like an Address very well could. Until we can support for-reals monads (which would require enums and generics to do properly; the former is possible the latter is very hard), it's the best option we have for more type-safe returns. --Larry Garfield