Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115773
MIME-Version: 1.0
References: <CAMrTa2HBv94ui0xGsqZwP=uL3AHQDMPAhaToo7m4F5Yh5QT64Q@mail.gmail.com>
 <2fd2d665-ca3a-4fa8-9196-6c8b1b2a3da0@www.fastmail.com> <CAMrTa2H9Y5PcyvQvgBieB_3nxGf9xHwOE-zijAGSBuwE7T6PqA@mail.gmail.com>
In-Reply-To: <CAMrTa2H9Y5PcyvQvgBieB_3nxGf9xHwOE-zijAGSBuwE7T6PqA@mail.gmail.com>
Date: Mon, 23 Aug 2021 06:37:00 -0700
Message-ID: <CAMrTa2HKaUS0yioyOE1+LD1mDx8hS=zJ0NhhNPd+1Yj-AjR6Eg@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000823feb05ca3a1d91"
Subject: Re: [PHP-DEV] [RFC] User Defined Operator Overloads
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--000000000000823feb05ca3a1d91
Content-Type: text/plain; charset="UTF-8"

Pierre and Dik,

The thread you were replying to is older and doesn't reference the current
RFC: https://wiki.php.net/rfc/user_defined_operator_overloads

This is the current discussion thread for the RFC.

In particular, I'd encourage reading about which operators are supported,
the restrictions on the implementations, and the failure mode behavior.

Pierre:
> and hell, if "->" doesn't mean "access that object member" anymore, but
"hey, the implementor could do anything at all instead", sky will fall upon
us.

I hate to break it to you, but __call and __get already do this, and aren't
even a part of this RFC. I'd highly encourage you to read what operators
are supported and how, because this RFC definitely does not suggest opening
ALL operators to overloads. There are very deliberate omissions.

However, the object accessor `->` is already overloadable to some extent
with `__call` and `__get`. The scope resolution operator `::` is already
overloadable to some extent with `__callStatic`. The string concatenation
operator `.` is already overloadable to some extent with `__toString`. The
**assignment operator** `=` is already overloadable to some extent with
`__set`.

These all have limitations in how they are called automatically however.
For instance, `__set` doesn't allow arbitrary overloading of the assignment
operator, instead it requires the left side to reference a class property.

Similar sorts of restrictions are proposed here. The fact that the
reassignment operators *must* be supported by any overload will very highly
discourage non-immutable implementations. The `__equals` overload must
return a bool. The `__compareTo` overload must return an int and will have
its return values automatically normalized to -1, 0, 1.

The RFC document covers a lot of detail about the proposed implementation
and addresses many of the things you brought up.

Jordan

--000000000000823feb05ca3a1d91--