On Sun, Dec 12, 2021, at 12:56 PM, Dan Ackroyd wrote:
> On Sat, 11 Dec 2021 at 17:46, Larry Garfield <larry@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