On Thu, Jan 30, 2020, at 3:22 PM, jan.h.boeh...@gmx.de wrote:
> > Unfortunately, this implementation goes in the wrong direction: PHP already
> > has full internal support for operator overloading through the do_operation
> > object handler. Operator overloading should be exposed to userland through
> > that handler as well.
>
> I have made another implementation
> (https://github.com/jbtronics/php-src/tree/operator_overloading) which
> provides an standard handler for do_operation, which calls the
> functions in user space.
>
> I also removed the __compare magic function from my implementation, so
> this can be handled separately.
I cannot speak to the implementation details. From a design perspective, I am
tentatively positive on operator overloading, with separate method for each
operator, BUT, the big question for me is the rules around type compatibility.
Can you only compare 2 of the same type? What about subclasses? Can that
differ if a subclass overrides that method? What happens to commutativity
then? Can you compare based on an interface?
Examples:
class Money {
public function __add(Money $m) { ... }
}
class Dollar extends Money {
public function__add(Money $m) { ... }
}
class Euro extends Money {
}
$m = new Money(5);
$d = new Dollar(10);
$e = new Euro(15);
What should happen in each of these cases?
$m + $d;
$d + $m;
$m + $e;
$e + $m;
$d + $e;
Or similarly, is this allowed:
interface Money {
public function __add(Money $m);
}
There's a lot of very tricksy logic here to work out in terms of what makes
sense to do before we could consider it. That logic may already have been
figured out by another language (Python, C#, etc.) in which case I'm perfectly
happy to steal their logic outright if it makes sense to do so. It's worth
investigating before we go further to see what the traps are going to be.
Also, I want to reiterate: Any of these operations MUST be designed to return a
new value, never modify in place. These operators only make sense on value
objects, not service objects, and value objects should be immutable.
Which means that there is no __addEquals() method, just _add(), and we continue
with that being isomorphic to $a = $a + $b;, the behavior of which is readily
predictable.
I've actually been wondering lately if we shouldn't create an entirely separate
data structure for value objects that helps enforce that difference of
expectation. (Similar to shapes in Hack, or records or structs in various
other languages.)
> Another thing: What are your opinions on overload the bitwise not
> operator (~)? My implementations offers every other bitwise operator
> and this one would complete the set of bitwise operators. On the other
> hand unary operators does not have much use for objects and maybe
> encourage people using them as "shortcut" for calling things on the
> object, where an explicit method call would make the intend function
> more clear.
Frankly I'd avoid bitwise operators entirely for now. I'm not even sure how
you'd use those...
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
