On Thu, Jan 7, 2016 at 8:18 PM, Sara Golemon <poll...@php.net> wrote:
> On Thu, Jan 7, 2016 at 5:16 AM, Nikita Popov <nikita....@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 picked the $g->add(123) example from your mail, maybe that was only a typo? To be clear, I don't really have a problem with something like $g->assignAdd(123) *as a performance optimization*. GMP is potentially critical code and depending on the application, the overhead of object and mpz allocations may be significantly higher than the cost of the operations themselves. My point here is only that I don't think these kind of mutable APIs on numbers are a good choice for being part of the primary, go-to API (which for GMP now are the overloaded operators). > > 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. > Thanks, that makes more sense. > >> 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) > Yeah, I totally agree with part 1+2 of the proposal :) Nikita
