> Am 03.01.2022 um 01:13 schrieb Jordan LeDoux <jordan.led...@gmail.com>: > > 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
Hey Jordan, thanks for bringing it up to a vote. I've voted for an inclusion, for the primary reason, that in general, it does, in fact, not get abused too much. It seems to me, that many of the no-voters fear codebases riddled with random operator overloads where they make no sense. I don't share that sentiment. Yes, there will always be some outliers, but it shouldn't hinder the general improvement it brings to readability and expressiveness. (I strongly disagree that gmp overloads are a net negative.) For my part, I have had a positive experience with operator overloads in C#. They tend to not be overused, make Vector operations graspable (once you have a mental model of what vector operations feel and look like…). In the past I've really hated writing, and especially reading math heavy code on something different than the standard euclidean space in PHP. (Vectors, complex numbers, integer spaces with a finite size…) I truly hope this RFC passes, so that these abominations of nested math calls may disappear. Bob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
