On Mon, Jan 3, 2022 at 5:38 PM Nikita Popov <nikita....@gmail.com> wrote:
> On Mon, Jan 3, 2022 at 1:14 AM Jordan LeDoux <jordan.led...@gmail.com> > wrote: > > > Hello internals, > > > > I've opened voting on > > https://wiki.php.net/rfc/user_defined_operator_overloads. The voting > will > > close on 2022-01-17. > > > > To review past discussions on this RFC and the feature in general, please > > refer to: > > > > - https://externals.io/message/116611 | Current RFC discussion > > - https://externals.io/message/115764 | Initial RFC discussion > > - https://externals.io/message/115648 | Pre-RFC discussion and > > fact-finding > > > > Jordan > > > > Voted No on this one. I did support the previous proposal on this topic, > but I don't like the changes that this iteration has introduced relative to > the previous proposal. > > The part that I dislike most (and that I consider an exclusion criterion > regardless of any other merits of the proposal) is the introduction of a > new "operator +" style syntax. I found the motivation for this choice given > in the RFC rather weak -- it seems to be a very speculative > forward-compatibility argument, and I'm not sure it holds water even if we > accept the premise. There's nothing preventing us, from a technical > point-of-view, from allowing the use of some keyword only with magic > methods. On the other hand, the cost of this move is immediate: All tooling > will have to deal with a new, special kind of method declaration. > I agree wholeheartedly with this. I don't have a vote but if I did I'd vote no. I think if operator overloading is to be introduced, new magic methods using names like __add and __equals are preferable for a number of reasons. > > I'm also not a fan of the OperandPosition approach, though I could probably > live with it. The previous approach using static methods seemed more > natural to me, especially when it comes to operators that do not typically > commute (e.g. subtraction). > > Regards, > Nikita >
