Re: [RFC] User Defined Operator Overloads (v0.6)
| From: | Dan Ackroyd | Date: | Sun, 12 Dec 2021 18:56:32 +0000 |
| Subject: | Re: [RFC] User Defined Operator Overloads (v0.6) | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-116628@lists.php.net to get a copy of this message | ||
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...
Larry Garfield wrote:
> It uses effectively the same operator sigil, though.
Yes, that's what I was trying to say.
Danack wrote:
> The name of the function (e.g. __add) always refers to the symbol used
> where it is used, not what it is doing.
If the naming is taken from the sigil, then it's always appropriate.
So if operator * has the magic method __asterisk instead of __mul, it
avoids any suggestion of what the operation actually means for the
object.
btw, I don't really care about this naming problem. My concern is that
it's being used as a reason for introducing a special new type
function, when it's really not a big enough problem to deserve making
the language have special new syntax.
cheers
Dan
Ack