On Sat, Aug 7, 2021 at 8:20 PM Mike Schinkel <m...@newclarity.net> wrote:
> > On Aug 7, 2021, at 10:28 AM, Larry Garfield <la...@garfieldtech.com> > wrote: > I strongly echo Larry's concern here. > > While I tend to be one who wants more language features, not less, the > availability of unconstrained operator overloading can beckon an > inexperienced and/or undisciplined developer to add operators for many of > the classes they implement, whether or not doing is actually applicable or > a good idea. > > I am even concerned about constrained operator overloading for the same > reason. Here [1][2] are a couple essays to argue against operator > overloading. > > Ruby has operator overloading, and one of the distasteful aspects I found > regarding in programming in Ruby was that everybody's Ruby code you looked > at felt like I was written in a slightly different language. I would hate > that to become the case with PHP, more than it already is. > > I am actually surprised that the last operator overload RFC came close to > passing because adding it seems like it would open a Pandora's box and yet > other proposals that are less Pandoric seem to be anathema on this list. > > That said, I am not unsympathetic to the fact that operator overloading > may well have some extremely valid use-cases, just ones that I do not > personally seem to need on a day-to-day basis when writing code. > > Operator overloading seems to me to be of more value to those who are > essentially wanting to write DSLs (domain-specific languages.) If that is > indeed the case, and there are some DSL like features I wish we could add > to PHP that would generally be non-starters for non-DSL usage. > > I wonder if there is a way to limit to only DSL use-cases? I doubt there > is, but I had to pose the question in case someone else can envision a way > to do so. > > So my main questions are: > > 1.) What are use-cases where operator overloading would really be > valuable? > > 2.) Would it possible that instead of adding operator overloading we could > add classes that could be extended where PHP actually defines the operators > for those classes? > > If we can do #2 we can really work through all the issues with > commutativity, associativity, etc. and also implement all and only the > operators that make sense for the use-case. > > > -Mike > > [1] > https://cafe.elharo.com/programming/operator-overloading-considered-harmful/ > [2] > https://www.joelonsoftware.com/2005/05/11/making-wrong-code-look-wrong/ > [3] https://externals.io/message/115554#115603 > [4] https://english.stackexchange.com/a/170247/1164 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > Hey Mike, Off the top of my head here are some of the use cases that I think benefit greatly from this: - Complex number objects - Fractions objects - Matrix objects (math) - Vector objects (math) - Time/Date intervals - Collections - Arbitrary precision numbers (which are usually represented as a string in PHP) Here are some actual user libraries which would probably use them: - samsara/fermat (this library is mine as a matter of disclosure) - brick/math - markbaker/complex - markbaker/matrix - krowinski/bcmath-extended - malenki/math - markrogoyski/math-php - rubix/tensor - numphp/numphp - mcordingley/linearalgebra The objects which represent a mathematical object that *cannot* be cast to either an integer or a float without losing their meaning are the ones that stand to gain the most. If you have an arbitrary precision number that will overflow both ints and floats, then even providing a method to cast them first doesn't help (that is, adding a __toInt() and toFloat() method would not help). Matrices and vectors cannot be converted to a meaningful scalar in any way that would allow the use of operators. Complex numbers *not only* can't be converted to an int or float, but as I've said in a few places, the correct behavior for the >, <, >=, and <= operators would be to throw an exception as these types of comparison are mathematically undefined for ZFC set theory. As for constraints... well, if I had absolutely no concern for implementation at all, and was just designing what constraints to put on the magic methods, they would be: 1. void is an unsupported return, and failing to return a value results in an error. 2. Variables outside the scope of the method cannot be set. This includes properties on the object which is defining the magic method, and includes sets that occur in called functions and methods. I think that the second restriction there would be quite difficult to accomplish in an implementation. Perhaps it could be done by creating a readonly temporary copy of the objects in question and then executing the magic method on that. In any case, it is certainly possible that we could instead implement some magic *objects* which can be extended that have built-in overloading in specific ways. I think this is actually worse for the following reasons: 1. It would be far less obvious to the programmer that an object would behave differently with a given operator, because the behavior wouldn't be documented in the code itself. 2. It would require many different implementations, some of them very close to each other, to cover the same set of use cases. 3. It would likely result in some maintainability concerns as more users demanded different DSL type implementations be included in core, and the existing ones would need to be maintained. As I've mentioned, while I understand that to many programmers commutativity is a requirement of a good language, it is explicitly incorrect to require commutativity for math operations. The arithmetic operators are commutative for the real numbers, but there are many valid math concepts for which they are not commutative, and I feel like pushing for commutativity is a mistake. It is an attempt to force a behavior that we want on code that it may be incorrect for. Jordan
