> Am 07.01.2016 um 20:29 schrieb Sara Golemon <poll...@php.net>: > On Thu, Jan 7, 2016 at 6:04 AM, Bob Weinand <bobw...@hotmail.com> wrote: >> I think this RFC is attempting to solve the wrong problem... Let me explain >> why: >> >> a) What do you do in cases like: >> $a = gmp_init(125); >> $b = $a; >> $b += 10; >> >> $a and $b hold the same object reference, so we'd need to do an implicit >> clone >> (separation) before passing it to the assign ops, or we are going to break >> the >> immutable-value-object assumption. >> > I do understand that. My point is that the immutable-value-object > assumption shouldn't be forced on every class which chooses to > implement overloading. It makes sense for GMP, so GMP should > certainly be allowed to implement it, but GMP's use case isn't > everyone's use case. > >> That risks to be be problematic. As long as it is internal, we could deal >> with it internally. >> When we leak operator overloading to userland, not so much. >> > That's a big IF, but I agree we should have a mind to that leak being > someday possible and not shoot our future selves in the foot.
Absolutely. >> b) The main goal is to not needing copies when unnecessary. This could then >> as well apply to simple cases like: >> >> $a = gmp_init(125); >> $b = $a + 10; >> /* $a isn't used anymore later */ >> or just explicit: >> $a = $a + 10; # instead of $a += 10; // under some circumstances that may be >> more readable... >> > I'm confused. Are you saying that avoiding copies is the main goal of > the RFC? Because no, it's not. Being able to take consistent when > implementing overloading is the main goal. An occasional win from not > having to clone is just a side benefit. > > Or are you saying that avoiding copies is a benefit of what we have > now, because it's not. What we have now is clone-always, regardless > of self-assignment. Hmm, re-read the RFC right now. Must have misunderstood something… you are saying the operations should apply to the objects behind and not to the variables? I think that's a bad idea. It's fine to optimize clones away, but I think having $a += $b; mean anything else (result-wise) than $a = $a + $b; is a bad idea (see below for why). >> At that point you would possibly rather explicitly check: "are we at the end >> of a variable range >> (if CV) and the refcount of the object == 1?" and eventually forward that >> information to >> userland as optional third param. >> Which would give you the most optimization possible; and even applicable in >> the example >> Nikita provided with sets. >> > I think that approach is piling a whole lot of complexity on for > minimal theoretical benefit. > > Again, this RFC is about correctness, not performance. I'd like to emphasize that by-object is everything, but not "by reference like" behavior. There's a big difference between: $a = gmp_init(125); $a = $b; $b += 2; // or $a = &$b: $b += 2; It would be a mistake to make both behaviors equal. After all, I consider operator overloading a static operation on two items yielding a new result. Another quirk here is: $a = gmp_init(125); $b = 5; $c = $b; $b += $a; // compared to $a = 5; $b = gmp_init(125); $c = $b; $b += $a; in first example (obviously!) we get $b != $c, but in the second one $b == $c with this RFC. Especially with GMP, we try to have faked by-value (which is very nice for pseudo-scalars). It'd basically make this impossible now. So, the big question boils down to: Is $a += $b; something different to $a = $a + $b; ? (As you say in the RFC.) My answer is no. Objects are not references. Operators operate on the variables, not on the values. Additional bonus point: This RFC requires that userland operator overloading will alter $this based on the operand passed in. But maybe we'll decide on another RFC promoting static functions with two operands (assuming binary operator) instead. In the latter case you might return in a div function of a Integer class an instance of Fractional instead. Do you then think this should happen: $a = new Integer(3); $b = $a; $a /= 2; $b instanceof Fractional === true?? I don't think so (that would be a very clear violation of by-object anyway). Hence, can we please delay further discussion until we really will have decided on the exact semantics of userland operator overloading? Bob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
