On Sun, Dec 12, 2021, at 12:56 PM, Dan Ackroyd wrote:
> On Sat, 11 Dec 2021 at 17:46, Larry Garfield <la...@garfieldtech.com> wrote:
>>
>> Using symbols, however, would (with some future extension to make it
>> extensible) allow for:
>
> I don't get how it's easier, other than being able to skip naming the
> symbol name. e.g. adding union and intersection operators
>
> function __union(...){}
> function __intersection(...){}
>
> vs
>
> operator ∪(...){}
> operator ∩(...){}
>
> In fact, I find one of those quite a bit easier to read...
If the list of operators is expanded by the engine, yes. The point is that IF
it were decided in the future to allow user-space defined operators, that would
be considerably easier with a separate keyword. Eg:
class Matrix {
operator dot(Matrix $other, bool $left) {
// ...
}
}
$result = $m1 dot $m2;
Whether that is something we want to do is another question, but the operator
keyword makes that logistically easy, while using __mul or __astrisk makes it
logistically hard.
Using an attribute instead to bind a method to an operator, as previously
suggested, would also have that flexibility if we ever wanted it. There seems
to be a lot of backpressure against using attributes for such things, though,
and it wouldn't cleanly self-resolve the issue of keywords that make sense on
methods being nonsensical on operators. (public, static, etc.). I'd probably
be fine with it myself, but I cannot speak for others.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
