[RFC][DISCUSSION] - Immutable classes and properties

On 12/11/2016 10:57 AM, Silvio Marijić wrote:

Some grammar issues: "After object is constructor" => should be "After the object's constructor has run". " If immutable property contains object, to preserve immutability, object that is beeing assigned to immutable property must also immutable." => "If an immutable property contains an object, then in order to preserve immutability the object being assigned must be of an immutable class." The File class/resource example should note that the last line in it will create a fatal error, as the earlier examples do. It's not clear that the example is an invalid one. In a few places, "If immutable property..." should be "If an immutable property..." There's several places where articles (the, an, etc.) are missing. "Notice in above examples removing getters and setting properties to public is optional. They simply doesn't need to be protected anymore in fact that immutable class objects are deeply frozen with eceptions on write." => "Notice in the above examples that removing getters and setting properties to public are optional. They simply don't need to be protected given the fact that immutable class objects are frozen on write." (Several grammar fixes, plus it's a fatal error, not an exception.) Content issues: Currently the only "unlocked context" for an object is its constructor. As discussed previously, that is insufficient. For any non-trivial object (more than 1-3 internal properties) creating a new one via the constructor only when incrementally building is prohibitively difficult. The pattern of with*() methods that spawn new objects via clone(), a la PSR-7, needs to be supported. That is: immutable class Money { // ... public function add(Money $other) : Money { $new = clone($this); $new->amount += $other->amount; return $new; } } I'm not sure how easily we can denote that sort of case. It's outside the __clone() function itself, which is what makes it difficult. Without that, though, such immutable objects are of only limited use. --Larry Garfield

2016-12-11 12:57 GMT-04:00 Silvio Marijić <marijic.silvio@gmail.com>:

Hi, Can you make a pull request? I'd like to comment the patch but it's not possible to make inline reviews only with a diff uri on github.

On 12/11/2016 5:57 PM, Silvio Marijić wrote:

-1 from my side for all the things previously mentioned. The copy-on-write topic must be solved along with the introduction of immutable classes or we end up with this being implemented and not way to mutate them in a controlled fashion. Also -1 on the proposed `copy` or `modify` function. Not only does it seem to allow anyone to mutate the immutable object, it also requires magic strings of the property names. No usage search, no refactoring, no ... I still strongly believe that `__clone` should be made `private` or `protected` for immutable classes to avoid useless cloning. After that we either stick to cloning as we currently do in our `with*` methods or we provide a keyword that changes the behavior of a method. I also propose to use `data` or `value` instead of `immutable` as the class modifier keyword. Its shorter and properly as well as fully communicates what kind of object we are building.

Hi Silvio, Silvio Marijić wrote:

The restriction that immutable properties may only hold immutable values seems potentially overzealous. Consider that not all immutable classes will actually be marked as such. Any code written in, say, PHP 7.2 if it included this feature, would not be able to make an immutable property if it pointed to an immutable object made before PHP 7.2 which couldn't use this feature. Another consideration is that your existing restrictions (only objects of immutable classes and resources) are not restrictive enough to achieve the desired end of enforcing deep immutability. Arrays can contain object values, as well as array values which might themselves contain values that are objects. They also can contain references. In order to enforce that immutable properties do not point to anything mutable, you would have to search any given array for mutable values, including sub-arrays. You would need to make sure you check for recusion here, lest assigning to an immutable property potentially crash the interpreter. This could be a significant runtime cost, it's at least an O(n) operation. I think that, realistically, trying to enforce immutability of values in an immutable class is not worth it, and makes the feature less useful. Consider that some popular applications of immutability ultimately contain a reference to something mutable: PSR-7's immutable HTTP message objects point to mutable streams, and Docker's immutable containers point to mutable volumes. Thanks.

Hi!

The RFC says:

I'm not sure - what concurrency are you talking about?

Value objects can be easily created right now if you follow generic best practices - private properties and no setters, here you go with value object.

allowing state modification. Not sure why it is a good thing to have public properties? Also, not sure how you are going to resolve references to such properties.