Re: RFC - Immutable classes

@Larry, Fact that $this in transformer method represents clone and the original object was my biggest concern, but again if you look at t from a point of view where that method describes transformation it doesn't look that bad. My initial idea was to introduce copy() method which would take as a first argument immutable object and as a second array of parameters which are going to be changed. If we decide for transformer method as a solution, I don't think it has much sense to allow cloning immutable object from user land. I think we can live with the fact that they are mutable only in a controlled way. But the fact that some solution for cloning is here is a great deal since that was issue from the day 1. Cheers, Silvio. 2016-09-06 18:01 GMT+02:00 Larry Garfield <larry@garfieldtech.com>: > On 09/05/2016 11:37 AM, Fleshgrinder wrote: > >> >> On 9/5/2016 10:26 AM, Michał Brzuchalski wrote: >> >>> I had a talk at Room11 and we discussed idea of mutator >>> keyword. >>> There were some concerns using mutator as a keyword - >>> that's because >>> immutable object is not being muted and also magically appeared >>> $clone >>> would be confusing. There's an idea of creating clone before function >>> begins >>> and operating simply on $this while it's newly >>> created clone from >>> immutable >>> object instance and the additional keyword for such method would be for >>> eg. >>> transformer, so basically it may look like this: >>> >>> immutable class Money { >>> public $amount = 0; >>> public $currency; >>> public function __construct($amount, $currency) { >>> $this->amount = $amount; >>> $this->currency = $currency; >>> } >>> public transformer function amount($newamount) { >>> $this->amount = $newAmount; // $this actually is newly created >>> clone >>> return $this; >>> } >>> } >>> >>> $oneHundret = new Money(100, $eur); >>> $twoHundret = $oneHundret->amount(200); >>> >>> How about that? >>> >> The thing about mutator is only partly true because setters are >> generally just called mutator, it does not state anything about how it >> mutates something. Note that the keyword might proof useful in >> nonimmutable classes too for other use cases in the engine. Hence, I >> would not throw it off board just yet. >> > > Naming things is hard. :-) While working on PSR-13 for FIG, we ended up > with the name "evolvable" for interfaces with the withFoo() methods. I am > not necessarily endorsing that as the best term (we weren't super happy > about it but it was better than the alternatives), but providing it as a > data point. > > > It is true that $clone might come as a surprise and that's why I >> proposed to pass it as the first argument to the mutator function. >> However, you were right that that is a suboptimal proposal (and it >> pretty much goes completely against my previous paragraph). >> >> However, always providing $this as a clone is also not a good idea >> because you might want to return the same instance. This really depends >> on the kind of action that is desired. >> >> It's probably much simpler to keep the clone requirement and unseal the >> clone while making the __clone method protected by default. >> >> immutable prototype { >> >> protected function __clone(); >> >> } >> >> immutable class Money { >> >> public $amount; >> >> public $currency; >> >> public function __construct(int $amount, Currency $currency) { >> $this->amount = $amount; >> $this->currency = $currency; >> } >> >> public function withAmount(int $amount) { >> if ($this->amount === $amount) { >> return $this; >> } >> >> $clone = clone $this; >> $clone->amount = $amount; >> >> return $clone; >> } >> >> } >> >> This might seem like we haven't achieved much compared to the current >> state of affairs but we actually did: >> >> 1. No introduction of additional keywords (besides immutable) >> 2. No surprises (magic $clone variable) >> 3. No hard limitation on cloning (but disallowed by default) * >> 4. Full freedom to developers when to clone >> 5. Full freedom to developers what to return >> >> * Simply because a hard limitation is not required. Let people clone the >> immutable instances if they want too. Nothing bad happens besides >> wasting performance. >> >> I think that this is the simplest and thus best solution. :) >> > > How big of a need is it to allow returning $this instead of $clone, and/or > can that be internalized somehow as well? With copy-on-write, is that > really an issue beyond a micro-optimization? > > As an end-user/developer, it's unclear to me how I'd know visually what > scopes an object can be modified in. Basically, in the above example > there's an implicit unlock-on-clone and lock-on-return. There's no clear > indication of that, however, since there's no extra keywords. Is that > sufficiently obvious for developers? I fear not. > > Also, would the above still allow for custom clone() implementations on an > immutable object or no? I' not sure off hand which I'd prefer, honestly.... > > Another note: This would preclude "externally immutable" objects, eg, ones > that can compute and internally cache a value but are still effectively > immutable as the outside world sees them. That's probably acceptable since > the manual way is still available, but I thought it worth calling out. > > I definitely like any of these options better than an explicit user-facing > lock/unlock mechanism, as that's begging for abuse, confusion, and > inconsistency. > > > --Larry Garfield > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Silvio Marijić Software Engineer 2e Systems