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 <ocram...@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.boeh...@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
> >
> >
>
