> On Jan 3, 2016, at 02:11, Nikita Popov <nikita....@gmail.com> wrote: > Thanks for the proposal, Sara! A few questions to clarify: > One point of order. It's Patricio's peoposal, I'm just helping him move it along.
> 1. If an object implements __add__, will $a += $b be equivalent to $a = > $a->__add($b) and ++$a be equivalent to $a = $a->__add(1)? This is how > internal operator overloading currently works (we have no separate overloads > for assign ops). Will this RFC also work this way? To be quite honest, I'd rather it DIDN'T work that way. As I said to Stas, I regard our current crossloading as broken since it forces new object creation when the statement visually calls for mutation. Semantically, what we do for GMP right now isn't sound, even if the distinction doesn't seem to be breaking anyone. > > 2. Regarding associativity, the RFC states "When both operands to a binary > expression implement operator overloading, the left-hand operand's handler > will be invoked. If only one of the two implement overloading, then that side > is invoked with the relative operation inverted as necessary." This sounds > rather fishy to me, as not all operations are abelian. In particular __sub, > __div, __pow and __concat are *usually* non-commutative. As such, the current > RFC does not appear to leave room for supporting things like 1/$complex or > 1-$complex or e**$complex. As such I wonder if these magic methods oughtn't > be static methods with two operands. > I did consider that as an alternate option. function overload_register($op, $lhtype, $rhtype, $callback); overload_type(ZEND_ADD, 'Complex', 'any', 'Complex::add'); This would get pretty expensive in terms of large lookup tables though, so I'm hesitant there. > 3. Relatedly, consider the situation where $obj1 op $obj2, where $obj1 and > $obj2 are instances of different classes, both of which have distinct > overloads of the op operator. It so happens that the op-implementation of > $obj1 does not support operations against $obj2, while the op-implementation > on $obj2 does support operations against $obj1. The op-implementation of > $obj1 will be invoked first -- will there be some way for it to signal "I > don't support this operation", thus allowing the op-implementation of $obj2 > to be used? > I do like the idea of being able to signal type failures. Would a specific exception be too heavyweight? Or just return "ConversionFailure" object instance or something... -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
