Re: [RFC] User Defined Operator Overloads

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