Hi! > 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. 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. Also, implementing them in consistent fashion would be non-trivial, and imagine what fun would be had when +, += and ++ work differently (btw, why have different implementations for + and += at all?). And then we get questions of commutativity and associativity... 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. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
