On 16/02/2020 14:13, jan.h.boeh...@gmx.de wrote:
Except for simple numbers, almost no mathematical objects define division
(only some special matrices can be on the right hand of a division, and for
vectors there is no definition for division at all).
Then my philosophical question would be: are those really the same
operation as we have for integers and floats, or are they
domain-specific meanings of the symbols?
Vectors and matrices, for instance, have multiple types of "product";
does exactly one of them directly correspond to multiplication, or would
* simply be overloaded with whichever named operation was most commonly
used?
Also think of time
differences: $datetime1 - $datetime2 results in a DateInterval, but
$datetime1 + $datetime2 is not a meaningful operation (Datetime already has
a diff() method that do this).
I'm not necessarily saying that the operations need to be symmetrical in
allowed types and behaviour, but there is at least a meaning to both
addition and subtraction in this case. And notably, DateTime +
DateInterval and DateTime - DateInterval *are* a symmetrical pair.
Also it is not really possible to split multiplicative and additive methods
into different behavior, as when $a implements Additive Behavior it should
be possible to do an -$a, but because of the the way PHP compiles the code
this becomes -1*$a.
That's a design decision; you could also treat it as equivalent to 0 -
$a and call the subtraction overload.
In my opinion this would lead to that even if an object implements these
interfaces, in many cases you cannot be sure that it really supports all
operations, which would contradict the whole idea of defining interfaces.
The value I see is not so much about checking the interface and assuming
particular behaviour, but encouraging developers to use the feature in a
certain way, if there is consensus that the feature is not intended for
Domain-Specific Languages.
Under the current RFC, I could write this:
/**
* Class to represent a Unix command
*/
class Command {
// ...
/**
* Implement $command1 | $command2
*/
public static function __or(Command $first, Command $second): Command {
return $first->pipeOutputTo($second);
}
}
If the operations were grouped into interfaces, I would be forced to
write this, making it much clearer that I am abusing the feature:
/**
* Class to represent a Unix command
*/
class Command implements BitwiseOperators {
// ...
/**
* Implement $command1 | $command2
*/
public static function bitwiseOr(Command $first, Command $second):
Command {
return $first->pipeOutputTo($second);
}
public static function bitwiseAnd(Command $first, Command $second) {
return PHP_OPERAND_TYPES_NOT_SUPPORTED;
}
public static function bitwiseXor(Command $first, Command $second) {
return PHP_OPERAND_TYPES_NOT_SUPPORTED;
}
public static function bitwiseNot(Command $operand) {
return PHP_OPERAND_TYPES_NOT_SUPPORTED;
}
public static function bitwiseShiftLeft(Command $operand, int $i) {
return PHP_OPERAND_TYPES_NOT_SUPPORTED;
}
public static function bitwiseShiftRight(Command $operand, int $i) {
return PHP_OPERAND_TYPES_NOT_SUPPORTED;
}
}
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
