Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:108334 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 29150 invoked from network); 31 Jan 2020 17:31:08 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 31 Jan 2020 17:31:08 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id D53471801FD for ; Fri, 31 Jan 2020 07:42:18 -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,SPF_HELO_PASS,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS11403 64.147.123.0/24 X-Spam-Virus: No X-Envelope-From: 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-smtp4.php.net (Postfix) with ESMTPS for ; Fri, 31 Jan 2020 07:42:18 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 0998D2FB for ; Fri, 31 Jan 2020 10:42:16 -0500 (EST) Received: from imap26 ([10.202.2.76]) by compute7.internal (MEProxy); Fri, 31 Jan 2020 10:42:17 -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=TkxAut zM0o4bwcHwek7RzAJZqFj6dV8BB+bZkjUFVM8=; b=kAFmvYi8pVSSS6Su71gt8P x+9SY3ysd/aQSLxanQBKDq55P83+Oi/8sPfc8BegXGPcsIcZZNwfRX3I5ZiVYhtp RWGnUlCXZ8eyiHfvP0e+WEjQ7DjB/buy5WgT1pxgDyIDMA9kUPm8X11sVfVOs2kV soS+Agv2L+bg5jSDF8d/Uq3R3W4IoHP9kMNY3if6+T/P7LVowdymFmXN1yFMUYLj fb3i8TteOm97fpA/d3EWLKEiK1KHDov9cPyJuOkMHpeiL2edRQmnEklmqnsHvWE1 ULyz/1t4VxDZ7s0nu9mkCGoBrSVXsQzqqPVxiLzD7ErEGHjwcPnd0jBgbZihTdpw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrgedtgdejudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfnfgrrhhr hicuifgrrhhfihgvlhgufdcuoehlrghrrhihsehgrghrfhhivghlughtvggthhdrtghomh eqnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucevlhhushhtvghrufhiiigvpedt necurfgrrhgrmhepmhgrihhlfhhrohhmpehlrghrrhihsehgrghrfhhivghlughtvggthh drtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6BE9A14200A2; Fri, 31 Jan 2020 10:42:16 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-781-gfc16016-fmstable-20200127v1 Mime-Version: 1.0 Message-ID: <7c915ed1-adcb-473d-a975-acfdbf7b1e33@www.fastmail.com> In-Reply-To: <001f01d5d7b3$68c18b10$3a44a130$@gmx.de> References: <00ea01d5d630$b18d4f20$14a7ed60$@gmx.de> <001f01d5d7b3$68c18b10$3a44a130$@gmx.de> Date: Fri, 31 Jan 2020 09:41:56 -0600 To: "php internals" Content-Type: text/plain Subject: Re: [PHP-DEV] Operator overloading for userspace objects From: larry@garfieldtech.com ("Larry Garfield") On Thu, Jan 30, 2020, at 3:22 PM, jan.h.boehmer@gmx.de wrote: > > Unfortunately, this implementation goes in the wrong direction: PHP already has full internal support for operator overloading through the do_operation object handler. Operator overloading should be exposed to userland through that handler as well. > > I have made another implementation > (https://github.com/jbtronics/php-src/tree/operator_overloading) which > provides an standard handler for do_operation, which calls the > functions in user space. > > I also removed the __compare magic function from my implementation, so > this can be handled separately. I cannot speak to the implementation details. From a design perspective, I am tentatively positive on operator overloading, with separate method for each operator, BUT, the big question for me is the rules around type compatibility. Can you only compare 2 of the same type? What about subclasses? Can that differ if a subclass overrides that method? What happens to commutativity then? Can you compare based on an interface? Examples: class Money { public function __add(Money $m) { ... } } class Dollar extends Money { public function__add(Money $m) { ... } } class Euro extends Money { } $m = new Money(5); $d = new Dollar(10); $e = new Euro(15); What should happen in each of these cases? $m + $d; $d + $m; $m + $e; $e + $m; $d + $e; Or similarly, is this allowed: interface Money { public function __add(Money $m); } There's a lot of very tricksy logic here to work out in terms of what makes sense to do before we could consider it. That logic may already have been figured out by another language (Python, C#, etc.) in which case I'm perfectly happy to steal their logic outright if it makes sense to do so. It's worth investigating before we go further to see what the traps are going to be. Also, I want to reiterate: Any of these operations MUST be designed to return a new value, never modify in place. These operators only make sense on value objects, not service objects, and value objects should be immutable. Which means that there is no __addEquals() method, just _add(), and we continue with that being isomorphic to $a = $a + $b;, the behavior of which is readily predictable. I've actually been wondering lately if we shouldn't create an entirely separate data structure for value objects that helps enforce that difference of expectation. (Similar to shapes in Hack, or records or structs in various other languages.) > Another thing: What are your opinions on overload the bitwise not > operator (~)? My implementations offers every other bitwise operator > and this one would complete the set of bitwise operators. On the other > hand unary operators does not have much use for objects and maybe > encourage people using them as "shortcut" for calling things on the > object, where an explicit method call would make the intend function > more clear. Frankly I'd avoid bitwise operators entirely for now. I'm not even sure how you'd use those... --Larry Garfield