Re: RFC Operator Overloading in Userspace

On Sat, Jan 2, 2016 at 6:59 PM, Stanislav Malyshev <smalyshev@gmail.com> wrote: >> Patricio Tarantino has asked me to help him propose Operator >> Overloading in PHP 7.1 (based in part on my operator extension in >> PECL). I think we can expose this to usespace as magic methods with >> very little overhead (the runtime check and dispatch is already there, >> after all). > > We could, but I'm not sure whether we should. One of the reasons why > userspace operator overloading was kept out was that a lot of its uses > make code worse, not better. When you see expression that looks like > addition but you know it can do literally anything, that makes reading > the code so much more frustrating. I mean, you can *hope* * still means > "multiply", but you can't know it anymore. And there are not that many > types for which * has natural meaning. > I can't argue with you there. Magic can be exceedingly dangerous in the wrong hands. I think the core question of this RFC is: Is the responsibility to use magic safely something to grant PHP developers. I'm personally not decided on it, which is why operator stayed a PECL extension and it's taken someone else to put the RFC forward (even if I am sponsoring him to get the discussion rolling). > Additionally, introducing about 9000^W^W a lot of new magics drastically > raises both cognitive complexity of the language (now we have 14 magics, > adding operators (and RFC lists only arithmetic ones, though one may say > why stop there - C++ certainly didn't) more than triples that count. > I think this can be handled by taking Bishop's suggestion. After all, it's how it's actually implemented internally via do_operation. We could apply the same to the userspace callback and simplify the implementation details, even if it add slight complexity to script implementations. > Also, implementing them in consistent fashion would be non-trivial, and > imagine what fun would be had when +, += and ++ work differently > Hilarious to hear you cite that as the already existing inconsistency between += and ++ with non-numeric strings came up only last week. $x = 'foo'; $x++; // $x === 'fop' $x += 1; // $x === 1 But I digress, your point is taken, and it comes back to the same thing in my first paragraph response. I think we can all agree that the potential for evil is great, the question is whether or not we trust developers with great power. > (btw, why have different implementations for + and += at all?). > Because the former would typically result in a new object, the latter wouldn't. In the case of GMP it's the difference between: $x = new GMP(1); $x = $x + 1; // Makes a new GMP instance and replaces $x $x = new GMP(1); $x += 1; // Updates the internal value of the GMP instance That's a significant difference in terms of semantics if there are other references to $x lying around. Nevermind the cost of newing/cloning/destroying objects when all you really wanna do is mutate an existing one a bit. > And then we get questions of commutativity and associativity... > Yeah, this was always one of my annoyances of pecl/operator. Honestly, I could see making them always-left-associative to avoid some unforseen wtf. But (if combined with the additional operations) would require resolving the commutativity that happens in ZEND_AST_GREATER* (not terribly complex to handle, but we'd have to decide to do it). > What I'm trying to say, doing proper operators set is not that trivial, > and besides a very small set of use cases, I'm concerned it would be > used to write very clever write-once read-never code instead of good code. > Not arguing with that at all. :) -Sara