Re: [VOTE] Userspace operator overloading

Hey Jan, Just posting here why I voted "no": it is not your implementation proposal, but rather the concept per-se that IMO shouldn't land in the language. Operator overloading makes call-site code reading extremely hard, and it makes the language much more complex for very little benefit. Everything suggested in the RFC can be done by using explicit arrows: -> (method calls), which lead to expressively named methods and parameters. I have posted similar thoughts about ->__toString() and ->toString() when it comes to cast operations vs explicit calls at https://github.com/ShittySoft/symfony-live-berlin-2018-doctrine-tutorial/pull/3#issuecomment-460441229 Overall, without type classes and infix functions, operator overloading is, IMO, just messy. Greets, Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ On Mon, Mar 23, 2020 at 6:58 PM <jan.h.boehmer@gmx.de> wrote: > Hi internals, > > I have opened voting on > https://wiki.php.net/rfc/userspace_operator_overloading, which > allows > users > to overload operators in their own classes. > > Voting closes on 2020-04-06. > > Regards, > Jan Böhmer > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >