From: Nikita Popov [mailto:nikita....@gmail.com] Sent: Sunday, June 09, 2013 5:15 PM To: Zeev Suraski Cc: PHP internals Subject: Re: [PHP-DEV] [RFC] Internal operator overloading and GMP improvements
On Sun, Jun 9, 2013 at 3:37 PM, Zeev Suraski <z...@zend.com> wrote: >> What I meant by cumulativity in that context is really commutativity ☺ >> Fixed (and also added transitivity). >> >> In other words, operands that are commutative in PHP (like addition, >> multiplication, etc.) – one should not overload for domains where they’re >> not commutative. > > Why? Mostly because I don't want us to have to worry about this when implementing the engine. It might side effects on optimizations that are valid when dealing with standard values - but not when dealing with these complex values. That said, you brought up a couple of examples where we already have different behaviors for $a+$b and $b+$a, so this point might be moot (mostly referring to the array part, I have a harder time accepting the floating point assertion although I understand why you're saying it...) > That's why I'm not sure it makes sense to have "too strict" definitions > for what is a valid overload and what isn't. I think "limited to cases > where there are clear definitions to > the behavior of all overloaded > operators" and "should be for mathematical use cases only" are enough as > guidelines :) I guess I can live with that (if nobody has any other additional thoughts on what we might be missing here). I can say that I mostly heard horror stories about operator overloading from my old C++ days - which is why I want us to do our best to avoid creating the same pitfalls in PHP. I do think that clear extension-level operator overloading support can be quite useful in some cases though (like gmp/bcmath). Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
