On Tue, Jan 5, 2016 at 7:17 PM, Sara Golemon <poll...@php.net> wrote:
> On Mon, Jan 4, 2016 at 1:39 AM, Nikita Popov <nikita....@gmail.com> wrote: > > I'd like to provide some context as to why the current implementation > works > > as it does. > > > Thanks for the context, Niki. It makes sense that, with GMP as the > flagship target of operator overloading, stripping away the by-ref > semantics of objects would be appealing. This way GMP objects just > look like regular numbers. > > Except they're not. Nor are they really objects at this point. They > have no methods, no properties, they're not instantiated with the new > keyword, and they have by-value semantics (mostly). > > That feels really odd to me, that GMP objects, at the moment of their > inception were /designed/ to be non-object objects. Would this carry > forward to any OOP API we might introduce in the future? i.e. > $g->add(123); wouldn't muttate $g, but would return a new instance? > 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.) 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. > 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. An example for such a case I came across today in an extension for collection objects, is the implementation of set union, intersection and symmetric difference using bitwise operators. Sets usually aren't immutable and $set |= $addSet creating a new object for the result would likely lead to much WTF with sets being passed around. > If the answer to that is "No" (which I think it is), then the question > is: Can we modify the do_operation API in a way that allows GMP to > remain psuedo-by-value while still allowing other internal objects > which implement overloading to be more correct? I think we can. > I'll cobble together a gist of how that might look if there's > tentative buy-in, but I'm pretty sure PHP7's variable model does let > us do that. 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 :) Nikita
