On Mon, 3 Jan 2022 at 22:15, Jordan LeDoux <jordan.led...@gmail.com> wrote: > > On Mon, Jan 3, 2022 at 9:07 AM Pierre <pierre-...@processus.org> wrote: > > > I forgot to answer to that, specifically. I'd much more prefer to have > > an explicit `equals(object $other): bool` (magic or not, really I do not > > care) single method for equality only, that'd be great. In that sense, I > > much preferred specific RFC about `__equalsTo()` or `__compareTo()` > > alone that a huge generic operator overload RFC. I think both could > > actually be separated, it wouldn't be that weird. > > > > Based on the feedback so far, I am... concerned that doing so would leave > the mathematical improvements out in the cold. It seems that a non-trivial > number of voters do not see mathematics as a desirable use case on its own. > > There's not really anything preventing that part from being ripped out on > its own, but the mathematical overloads add almost no complexity on their > own to the patch. One of my main goals in contributing to PHP is to improve > its usability and performance in mathematics. > > Using magic methods instead of the operator syntax would take perhaps 2 > hours to implement, it's a fairly trivial change in the scope of the RFC. > However, I have no plans to bring this back in time for 8.2 should it be > declined with a magic method implementation. Fundamentally, there are many > voters that seem to be more concerned about possible abuse that empirically > does not exist in most languages which have this feature, instead of > improvements to one of the most neglected domains PHP is used in. > > And that's the real crux: *most* (but not all) of the objections raised so > far suggest a future that factually does not exist in the example languages > we can look at which already have this feature. C++ is perhaps the one real > example of widespread abuse, however there are *multiple* aspects of this > RFC which *specifically* target and discourage that kind of abuse. > (Explicit typing of parameters, non-optional support for implied operators, > restrictions on the return types of the == and <=> operators, errors and > exceptions being propagated immediately, etc.) > > Further, the operand is not passed by-reference in this implementation, > which flatly excludes many of the worst possible abuses. > > I understand all of these objections, but I do not agree with them. > Obviously. If I did, then I wouldn't bring this RFC to a vote. What I have > proposed is the most restricted version of operator overloads in any > language I researched, and that is still not enough for many voters, some > of whom have flatly stated that there is no version of this feature they > would ever vote for. If that is the kind of headwind against quite > fundamental improvements to mathematics within the language, then all of my > energy will be required to produce any improvement at all, and I cannot > spend effort on things which are unrelated.
To me it is not surprising that an RFC like this would be controversial. We could enter a wonderful new era of value objects with operators, but it is hard to envision that beforehand. The best might be to find and advertise with use cases and examples from other languages. (as mentioned, I don't really know where to start looking, otherwise I would have already shared something) > > Jordan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
