On 12/12/2021 17:32, Larry Garfield wrote:
The only mitigation for unnecessary complexity I can think of is to force
overloaded operators to be "arrow functions" to encourage only minimal
code, e.g.
operator +(Number $other, OperandPosition $operandPos): Number => return
new Number ($this->value + $other->value);
I don't think that would be possible. As many of the examples in the RFC show,
there are numerous cases where an operator function/callback/thing will need
branching logic internally. Even if we did that, people could just sub-call to
a single function which would be just as complex as if it were in the operator
callback directly.
I don't know if this would actually be helpful, but you could *force*
the operator definition to be an alias for a normal method. That would
(at least partially) solve the "dynamic call" problem, because the
underlying method would be available with the existing dynamic call syntax.
Perhaps we could use an Attribute to bind the operator to the method,
which would also reduce the impact on tools that need to parse class
definitions:
class Collection{ #[Operator('+')]
public function union(Collection$other, OperandPosition$operandPos) {}
}
An interesting extension would be to have an optional argument to the
Attribute which binds separate methods for each direction of arguments,
rather than exposing it as a parameter:
class Number{ #[Operator('/', OperandPosition::LeftSide)]
public function divideBy(Number $divisor) {}
#[Operator('/', OperandPosition::RightSide)]
publicfunction fractionOf(Number $dividend) {}
}
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
