Hi Nikita, On Tue, Jan 4, 2022 at 12:38 AM 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'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).
I hesitated too, however I think we can't escape this feature. Like it was for the annotation, we need to find a compromise. Your points are valid so I wonder if the RFC could be modified and get to the point we could reach that compromise. There will be the oppositions for the features as a whole, however I am optimistic about our abilities to get there this time rather than wait yet again a few years for something we know we will have anyway. Best. -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
