Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:108337 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 45538 invoked from network); 31 Jan 2020 19:21:03 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 31 Jan 2020 19:21:03 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 4F02718055F for ; Fri, 31 Jan 2020 09:32:12 -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=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-yw1-f66.google.com (mail-yw1-f66.google.com [209.85.161.66]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Fri, 31 Jan 2020 09:32:10 -0800 (PST) Received: by mail-yw1-f66.google.com with SMTP id l22so5451464ywc.8 for ; Fri, 31 Jan 2020 09:32:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=newclarity-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cR7jYvPIzYfjSAmy4bJiKsiLneTe5tC7lje40o6gsMw=; b=PTzubSMVmJl3IkOzn6Vh61LWO7MA/u5xK74OPafHgSi/wvcnDpyWF7hw1TtboNK7/b plLtPU0UgL5ztAxEOubKEq0Tu9ftXnnpeSfKRiSv6wgu17Pfo6g9NefzzgUsu75fh7r+ hljzi8ALkNSNju9HcLtSvEGWeEB8H5hVDlJqZHkxgxCD31uvX+FnVe4r3S8/8TXc5xi7 XN+BleaQ/paOFqY2z1wsj7m0MWYdfUES5wC8R7m2RgTygvQgeBaWg/qDKdGPL+fkwfsE xq+/u0jUoY/WoeBoN1bY1FkHiW4/dCIZeD86vc3hT710jcRtVnCQ9Y89MNZkh0JzSe0g +tAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cR7jYvPIzYfjSAmy4bJiKsiLneTe5tC7lje40o6gsMw=; b=OQhiaphixtKb1btXXBAj0JGag08gWjJ8jUM9h4Ek01+mOS/zyjNO7RnOmweNJjAbVj KMIGxSRqX/fiZ2ZMeJv5aK8yl0swLk7A2qd2OQ9nOm6h1aV7qzmsQLYISqXyTe7IAyas Z/dfbIYvl/N+ifpq9ICTDejXgxnjFLKGMtR5D54gt4InYFJcb8by183kg5Yq5Htld7KM cqcSp0YWpcNRJdavosoiNLLsRBYq4tPGHar4HqbnHsVIgi/VptM7ERU0uR3bXyvkXQpZ iNbrDFpr9vN0ysn61HFkD/i7C2ro7LNXxUsyIs0Zr1klIHUsvc878DKBGh342lqqCK9u 8tQg== X-Gm-Message-State: APjAAAUSMrXj+tCE5q6P4YbYRHWI1QsonaVcs5r+1NF/wZvcwAuHfZF3 jspQerylU+gYIT57IBLrDlRNCQ== X-Google-Smtp-Source: APXvYqxT951RwhXhs7UjhyhDcsf6IZBsMmEtjsaTSjCfxoxmGFOBNJF4oVeZOv6xc2ET/70ihvLsng== X-Received: by 2002:a81:138f:: with SMTP id 137mr8720382ywt.364.1580491928788; Fri, 31 Jan 2020 09:32:08 -0800 (PST) Received: from ?IPv6:2601:c0:c680:5cc0:2d7c:680f:ce7c:8e81? ([2601:c0:c680:5cc0:2d7c:680f:ce7c:8e81]) by smtp.gmail.com with ESMTPSA id p62sm4384162ywc.44.2020.01.31.09.32.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Jan 2020 09:32:07 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) In-Reply-To: <7c915ed1-adcb-473d-a975-acfdbf7b1e33@www.fastmail.com> Date: Fri, 31 Jan 2020 12:32:06 -0500 Cc: php internals Content-Transfer-Encoding: quoted-printable Message-ID: <58F2F26E-3082-4A32-828C-80491F9ED430@newclarity.net> References: <00ea01d5d630$b18d4f20$14a7ed60$@gmx.de> <001f01d5d7b3$68c18b10$3a44a130$@gmx.de> <7c915ed1-adcb-473d-a975-acfdbf7b1e33@www.fastmail.com> To: Larry Garfield X-Mailer: Apple Mail (2.3445.104.11) Subject: Re: [PHP-DEV] Operator overloading for userspace objects From: mike@newclarity.net (Mike Schinkel) > On Jan 31, 2020, at 10:41 AM, Larry Garfield = wrote: >=20 > I cannot speak to the implementation details. =46rom 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. I have avoided commenting on this thread to see where it would lead. I = have been surprised so many here are embracing operator overloading. =20 My experience taught me operator overloading has been added to languages = because "it seemed like a good idea at the time." But it is now = considered to be harmful, by many: - https://www.quora.com/What-are-the-pitfalls-of-operator-overloading - = https://cafe.elharo.com/programming/operator-overloading-considered-harmfu= l/ - = https://www.oreilly.com/library/view/sams-teach-yourself/0672324253/067232= 4253_ch21lev1sec4.html - https://en.wikipedia.org/wiki/Operator_overloading#Criticisms - = https://www.jarchitect.com/QACenter/index.php?qa=3D53&qa_1=3Doverload-oper= ators-special-circumstances-defined-literals (Ruby's ability for developers to redefine the entire language is an = especially chilling example of the concepts of operator overloading = taken to the extreme: https://dev.to/jimsy/please-stop-using-ruby-4lf1)=20= That said, I will not protest further if others still really feel = strongly about adding operator overloading after reviewing those = criticisms. > 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. >=20 > Which means that there is no __addEquals() method, just _add(), and we = continue with that being isomorphic to $a =3D $a + $b;, the behavior of = which is readily predictable. Immutability is a great feature from functional programming. But I think = it is orthogonal to operator overloading as it would be (relatively) = easy to implement an __add() method but how would PHP enforce that = __add() would not be able to mutate state? Consider the following. How would __add() stop the mutating happening = in $foo->bar->increment_ops()? =20 class Bar { private $_op_count =3D 0; function increment_ops() { $this->_op_count++; } } class Foo { public $value; public $bar; function __construct( int $value ) { $this->value =3D $value; } function __add( Foo $foo ): Foo { $this->bar->increment_ops(); return new Foo( $this->value + $foo->value ); } } $foo =3D new Foo(10); $foo->bar =3D new Bar(); $foo =3D $foo + new Foo(5); echo $foo->value; I am sure it would be _possible_ to stop it, but I do not think it is = trivial to architect nor implement. Given that I believe immutability = would need to be implemented as an independent feature and not as an = aspect of operator overloading.=20 If we still want operator overloading and we want to force operator = overloading to require immutability, I believe that means we would need = an immutability RFC to be approved (and implemented?) before operator = overloading requiring immutability could be approved. Something like = this: class Bar { private $_op_count =3D 0; immutable function increment_ops() { global $foo; $foo =3D new Foo(); <=3D=3D=3D=3D=3D=3D Compile error! $this->_op_count++; <=3D=3D=3D=3D=3D=3D Compile error! } } > I've actually been wondering lately if we shouldn't create an entirely = separate data structure for value objects... +1 for that.=20 -Mike