Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:107838 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 15183 invoked from network); 19 Nov 2019 22:27:47 -0000 Received: from unknown (HELO php-smtp3.php.net) (208.43.231.12) by pb1.pair.com with SMTP; 19 Nov 2019 22:27:47 -0000 Received: from php-smtp3.php.net (localhost [127.0.0.1]) by php-smtp3.php.net (Postfix) with ESMTP id 83D832D20B7 for ; Tue, 19 Nov 2019 12:20:44 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp3.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,SPF_HELO_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS11403 64.147.123.0/24 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp3.php.net (Postfix) with ESMTPS for ; Tue, 19 Nov 2019 12:20:43 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 3A455535 for ; Tue, 19 Nov 2019 15:20:42 -0500 (EST) Received: from imap26 ([10.202.2.76]) by compute7.internal (MEProxy); Tue, 19 Nov 2019 15:20:42 -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=Tqb08e O9WFE4Vqle69tcqf6fsJpC7nmTIde4WHdMEww=; b=VNSeoyGB9C/A41c+vYTKO+ gWWNMUnpJeYAqjQpYAnMlwMn4gRm7WD/SrwpG2MWfiT/L9ce67Pour69y1gFRKkU EchdgnIBYBP0ex2C8rixECw7epdi+z1MXF339xzvelhvyylzNWVwVb+Doy0A/1Ul fRMoSvRa+XPcs1RldqjIbZAgqT+3HvSEiFzGaIcB/OW6Q8KwUTnvVEvivcteNce8 BVPTy8X/asMIWVPwazGLfprWcnmReoDOmIEunBjtU0xIft5tqbe2+gMKThHT3TyU +FaR4Njr9GcGrS/jz96eULrt2/VAVcBThxNfHEw8xBP3cQoZNnCLiMZ0hhlTHa1g == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudegkedgudefjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtsehttdertderreejnecuhfhrohhmpedfnfgr rhhrhicuifgrrhhfihgvlhgufdcuoehlrghrrhihsehgrghrfhhivghlughtvggthhdrtg homheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehlrghrrhihsehgrghrfhhivghlught vggthhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 57DCD14200A1; Tue, 19 Nov 2019 15:20:41 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-578-g826f590-fmstable-20191119v1 Mime-Version: 1.0 Message-ID: <053cf110-af30-405e-81f8-873de3f0aadb@www.fastmail.com> In-Reply-To: References: <461958fe-182e-59bf-9fdb-b110fd09e2b2@aimeos.com> <08de5448-3c5a-ad32-555e-b8f9579c1337@aimeos.com> <7b527bbb-47e3-9b24-8766-c15e6334c78a@gmail.com> <1BF6C8EC-6DF1-4481-94B2-3A6E7D1312BE@newclarity.net> <2814FAA1-3BEC-47CF-A95E-AE61A33B7308@newclarity.net> Date: Tue, 19 Nov 2019 14:20:20 -0600 To: "php internals" Content-Type: text/plain X-Envelope-From: Subject: =?UTF-8?Q?Re:_[PHP-DEV]_Concept:_"arrayable"_pseudo_type_and_\Arrayable_?= =?UTF-8?Q?interface?= From: larry@garfieldtech.com ("Larry Garfield") On Tue, Nov 19, 2019, at 9:54 AM, Rowan Tommins wrote: > Yes, I would see that as a better example. I think operator overloading in > general makes sense when the object itself can be thought of as a > special-case of the primitive it's emulating operators for. So in this > case, the IsSuccessful class would be "a special kind of boolean"; and the > hypothetical List or Collection classes I mentioned a couple of days ago > would be "a special kind of array". We even have that in PHP for built-in > types: GMP objects can now be used with mathematical operators like $foo * > $bar, and those operations do what you'd expect them to do on an integer or > float. > > Operator overloading can also be used just as a cute way of spelling > something - probably most famously, C++ uses the << and >> operators for > writing to and reading from streams, even though they're actually overloads > of the bit-shift operator. This kind of use is, I would say, more > controversial - going back to consistency, it's easier to reason about code > if $foo * $bar always does some kind of multiplication than if it's been > overloaded to mean "$foo is the star of $bar". > > Overloading of cast operators is no different - the clearest use cases for > __toString() are where the whole class basically represents a piece of > text, and the more controversial are where (string)$foo is actually a cute > spelling of one method on a complex class. I just want to pop in here to highlight this last point, because that's the best heuristic I've seen for when __toString() is appropriate or not. I may have to steal that heuristic because it's spot on. To the rest of the thread, I think it's wise to split discussion of __toArray() off from "arrayable". They seem like they are addressing different if related problems. While an object with __toArray() would be "arrayable", there's already 2 array-ish things: arrays and the ArrayAccess interface. So some short hand for array|\ArrayAccess can stand on its own as a proposal. Or, since we now have union types, maybe that makes such a shorthand no longer necessary. I'm not sure there. --Larry Garfield