Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:89981 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 55036 invoked from network); 4 Jan 2016 00:29:53 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Jan 2016 00:29:53 -0000 Authentication-Results: pb1.pair.com header.from=larry@garfieldtech.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=larry@garfieldtech.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.28 cause and error) X-PHP-List-Original-Sender: larry@garfieldtech.com X-Host-Fingerprint: 66.111.4.28 out4-smtp.messagingengine.com Received: from [66.111.4.28] ([66.111.4.28:37404] helo=out4-smtp.messagingengine.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 84/55-28689-DFCB9865 for ; Sun, 03 Jan 2016 19:29:50 -0500 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 60BF220361 for ; Sun, 3 Jan 2016 19:29:46 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Sun, 03 Jan 2016 19:29:46 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=Sb20c0YqJXtWnJOGEJL2l1b7mOE=; b=FRmR1 PUfyIJ06/71kx7Kzxr1qmlYAAGiLF3X4ZWbzQ9yVOnw8JN/DKiZZ/yuyyr3u7J23 avtN2MkrB4uL4yyIyAj3D6frynjc+/atkMC+WgId7ifFozDT+wbqwsy35AvEv7jf zOefr6Iwtd1jhvYfeyYXBY9UQpiwPtk8m53aS8= X-Sasl-enc: p9JpMScftBShrrylNZWdvkAJQfZWwlZWLZIi9GrEsIRp 1451867386 Received: from [192.168.42.5] (c-50-178-40-84.hsd1.il.comcast.net [50.178.40.84]) by mail.messagingengine.com (Postfix) with ESMTPA id 055C268016C for ; Sun, 3 Jan 2016 19:29:45 -0500 (EST) To: internals@lists.php.net References: Message-ID: <5689BCF9.8020109@garfieldtech.com> Date: Sun, 3 Jan 2016 18:29:45 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------050603080304090602000403" Subject: Re: [PHP-DEV] RFC Operator Overloading in Userspace From: larry@garfieldtech.com (Larry Garfield) --------------050603080304090602000403 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 01/02/2016 08:14 PM, Sara Golemon wrote: > Patricio Tarantino has asked me to help him propose Operator > Overloading in PHP 7.1 (based in part on my operator extension in > PECL). I think we can expose this to usespace as magic methods with > very little overhead (the runtime check and dispatch is already there, > after all). > > I do think that the "Future Expansion" section bears following through > with as well, but the basic set of methods already hooked for GMP > would be a nice start. > > https://wiki.php.net/rfc/operator-overloading > > -Sara I'm really torn here. First off, IF PHP were to adopt such overloading, I would much prefer special interfaces over magic methods. It's simply far more self-documenting and reduces the difference between user-space and PHP-space features. (And I'd be all for migrating the current magic methods to that, too, if we wanted consistency.) That said... as Stas notes the can of worms this entails is quite large. I've started thinking more in terms of pure value objects in the past year (PSR-7-inspired), and for those, having richer operations can be quite useful. DateTime, for instance, supports > and <, which would be similarly helpful on other value objects. Think money for a good example, or object-based collections. It also serves to improve the type system, as a Currency object could allow itself to be added iff the other Currency object was in the same denomination. That said, the potential for magic "WTF were you thinking?" there is also scarily large. Stas hinted at an example, as does the RFC itself. From the first example: public function __add($rhs) { $ret = clone $this; if ($rhs instanceof Complex) { $ret->real += $rhs->real; $ret->imaginary += $rhs->imaginary; } else { $ret->real += (int)$rhs; } return $ret; } That all seems reasonable. Return a new object that is the result of adding the real and imaginary components together. Cool. I give it about 8 minutes before someone forgets to clone $this first and just starts returning $this, in which case you now have an addition operator that both modifies a value in place *and* returns itself. I then give it about 4 minutes after that before someone tries to defend that as a good practice, and now we have a large cadre of people who will insist that $c = $a + $b; modifying $a along the way is "totally a legit thing, it's a performance optimization, stop being so pedantic telling me I shouldn't do that!" (Come on, you know that's going to happen.) The worst-case scenario there is not guaranteed, but it still scares the bejeebus out of me. So for the moment, I'm tentatively -1. Perhaps limiting it for now to the obviously immutable operators, ie the comparison operators only, would be a safe babystep? --Larry Garfield --------------050603080304090602000403--