Re: [RFC] Differentiate op from assign-op in operator overloading

On Thu, Jan 7, 2016 at 5:16 AM, Nikita Popov <nikita.ppv@gmail.com> wrote: > GMP objects are, with the exceptions of gmp_setbit and gmp_clrbit, immutable > value objects. And yes, that's exactly what I would expect any object > representing a number to be. If $g->add(123) would modify $g instead of > returning a new object, that would be a major WTF moment for me (and for > that matter, make the usage very inconvenient.) > Sure, but if I called $g->assignAdd(123); then I would expect $g to be modified. That's the analogue to += so I while I don't disagree with your conclusion about add(), I do disagree with your analogy. > I don't get why you denounce immutable value objects as being "non-object > objects". Seems like very standard usage to me, and one that seems to be > increasingly preferred. > It's not their immutability which makes me call them that. It's the lack of anything you would normally see on an object: * No methods * No properties * No constants * Not initialized via new GMP objects are just resources by another name, and operator overloading got built around that model, rather than the model enjoyed by normal objects. That's why I denounce them as non-object objects. >> Leaving GMP out of the equation for now (and I think we need to have a >> longer discussion about this, but in another thread), I think the >> question which remains is: Do we want more non-object objects? >> Should, for example, SimpleXMLbe constrained by GMP's goals when >> implementing overloaded operators (no, I don't know what this would >> look like, it's just a for-instance). > > > If we leave GMP out of the equation, then yes, I agree. Whether $a op= $b > should create a new object or modify an existing one depends on the nature > of that object. For GMP (and Rational and Complex and Currency and most > other things that tend to be immutable value objects) I think the behavior > we currently provide is preferable (though I guess that is subject to > discussion), but for some other applications of operator overloading, this > choice wouldn't really make sense. > Agreed. The choice of mutability needs to be class specific, which is why I propose letting the class enforce it rather than dictating it from the engine and not giving the classes a choice. > It's currently already possible to distinguish this based on whether result > == op1. However we reserve the right (i.e. have some currently non-default > optimizations doing that) to have result == op1 in $a = $a + $b operations > as well, so this check is not robust. So, it would be good to change things > to pass in separate ZEND_ASSIGN_* flags. Will make the implementation even > more ugly though :) > Right, that optimization pass is slightly more complex. I haven't had the bandwidth to dig into it, but assuming a clean/efficient solution is available, would you be okay with the rest of the proposal overall? (Non-binding) -Sara