Re: RFC Operator Overloading in Userspace

> Am 4.1.2016 um 20:39 schrieb Johannes Schlüter <johannes@schlueters.de>: > > On Sat, 2016-01-02 at 18:14 -0800, Sara Golemon wrote: >> https://wiki.php.net/rfc/operator-overloading > > Back in the days when I created the first implementation of operator > overloading in the engine[1] I didn't see it fit for the language. > Meanwhile we have more type hints and stuff making it a bit less magic. > I still don't think this approach is really good. for instance we loose > associativity; taking the Complex example: > > <?php > $a = new Complex(1, 2); > $b = 3; > echo $a + $b; // works > echo $b + $a; // will error out > ?> > > Of course this can easily be fixed by looking at the order, at least in > this simple case. In a more complex example where a function might > return an integer, double or complex number this becomes more > complicated. > > For this to work we'd need non-member functions to do this and we need > function overloading ... > > I believe we'll only get a half-baked solution and I prefer the current > state over half-baked. > > johannes > > [1] http://news.php.net/php.internals/14558 Then that must be very long ago, as, looking at code even as old as 5.6, http://lxr.php.net/xref/PHP_5_6/Zend/zend_operators.h#959 <http://lxr.php.net/xref/PHP_5_6/Zend/zend_operators.h#959> clearly checks both operand for object with custom do_operation. The only issue is when you try to compare two objects with each custom operation handlers, like, e.g. an instance of Complex and Fractional. To have that working, we couldn’t just use real fractionals, but would need a special ComplexFractional, as Fractional may not be aware of Complex. This really is the limit of this abstraction… But I guess, it won’t be too much of an issue in real world. Bob