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
