Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108340
User-Agent: Cyrus-JMAP/3.1.7-781-gfc16016-fmstable-20200127v1
Mime-Version: 1.0
Message-ID: <89b8de30-a141-4802-953d-eb66c684244c@www.fastmail.com>
In-Reply-To: <58F2F26E-3082-4A32-828C-80491F9ED430@newclarity.net>
References: <00ea01d5d630$b18d4f20$14a7ed60$@gmx.de>
 <CAF+90c8h8dBhM=12ifxBJsWGcgVkjXHmmvKkPo_xCjUvZ++XdQ@mail.gmail.com>
 <001f01d5d7b3$68c18b10$3a44a130$@gmx.de>
 <7c915ed1-adcb-473d-a975-acfdbf7b1e33@www.fastmail.com>
 <58F2F26E-3082-4A32-828C-80491F9ED430@newclarity.net>
Date: Fri, 31 Jan 2020 18:03:05 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] Operator overloading for userspace objects
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, Jan 31, 2020, at 11:32 AM, Mike Schinkel wrote:
> > On Jan 31, 2020, at 10:41 AM, Larry Garfield <larry@garfieldtech.com> wrote:
> > 
> > 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.
> 
> I have avoided commenting on this thread to see where it would lead.   
> I have been surprised so many here are embracing operator overloading.  
> 
> 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-harmful/
> - 
> https://www.oreilly.com/library/view/sams-teach-yourself/0672324253/0672324253_ch21lev1sec4.html
> - https://en.wikipedia.org/wiki/Operator_overloading#Criticisms
> - 
> https://www.jarchitect.com/QACenter/index.php?qa=53&qa_1=overload-operators-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) 
> 
> That said, I will not protest further if others still really feel 
> strongly about adding operator overloading after reviewing those 
> criticisms.

Those are valid points.  (Hence my "tentatively.")  Operator overloading is one of those features that when used well can be really really nice, but is really easy to use badly (in which case it's really really not nice).

In all honesty, I'd probably be more excited about bringing back comparison overloading (__compare() and __equals()) than overriding arithmetic.  Unless we could get some kind of bind operator, but that's probably asking for trouble. :-)

> > 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.
> 
> 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?

Currently it cannot.  That's another point of concern.  We could at best document it and put "please please don't modify the object" in the docs, but that would probably work just as well as you think it would...

All of this is pointing in the "we need a language construct for value objects" direction, which I believe would be highly useful but I don't know how we'd do it nicely.  (Mainly, how to handle what PSR-7 does with withX() type methods, which are clunky but the best we can do without some really funky new syntax.)

--Larry Garfield