Re: [VOTE] Userspace operator overloading

I accept that it adds an extra level of understanding to the language – if you see function addAmounts($a, $b) { return $a + $b; } you no longer definitely know the answer will be numeric. However, I imagine that the sorts of people who will use this are _also_ the sorts of people who would add type annotations clearly – so you'd much more likely see function addAmounts(CurrencyAmount $a, CurrencyAmount $b) { return $a + $b; } where it's trivial to understand that there's userspace operator overloading going on. On Tue, 24 Mar 2020 at 06:04, Marco Pivetta <ocramius@gmail.com> wrote: > 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 > > > > >