rfc:immutability

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
rfc:immutability [2016/12/02 14:24] – marijic.silviorfc:immutability [2018/02/20 11:19] (current) – marijic.silvio
Line 1: Line 1:
 ====== PHP RFC: Immutable classes and properties ====== ====== PHP RFC: Immutable classes and properties ======
-  * Version: 0.1 +  * Version: 0.2 
-  * Date: 2016-08-12+  * Date: 2018-02-19
   * Author: Michal Brzuchalski <michal@brzuchalski.com>   * Author: Michal Brzuchalski <michal@brzuchalski.com>
   * Author: Silvio Marijic <marijic.silvio@gmail.com>   * Author: Silvio Marijic <marijic.silvio@gmail.com>
-  * Status: In Draft+  * Status: In Discussion
   * First Published at: [[rfc:immutability|https://wiki.php.net/rfc/immutability]]   * First Published at: [[rfc:immutability|https://wiki.php.net/rfc/immutability]]
  
 ===== Introduction ===== ===== Introduction =====
  
-This RFC proposes introduction of immutable classes and properties. Currently the only way of achieving immutability is trough encapsulation. Because of that user-land applications are using third party libraries or resort to custom implementations and still there is no easy enforcement of immutability. Introducing this feature would help bring one unified solution to this problem, and also it would remove unnecessary logic from user-land applications. +This RFC proposes the introduction of immutable classes and properties. Currently, the only way of achieving immutability is through encapsulation. Because of that, user-land applications are using third party libraries or resort to custom implementations, but there is still no easy enforcement of immutability. Introducing this feature would help bring one unified solution to this problem, and also it would remove unnecessary logic from user-land applications. 
-If those mechanizsm is utilized, developer can be sure that he is programming with no side effects, meaning that state of the object can not be changed with developer beeing unaware of that. This especialy comes hand in hand with concurrency when we can guarantee that threads will always read the same value.+If this mechanism is introduced, developers can be sure that they are programming with no side effects, meaning that state of the object can not be changed without developers being made aware. This is especially useful when dealing with concurrency, where we can guarantee that threads will always read the same value.
  
  
Line 18: Line 18:
   - Safe for concurrency.    - Safe for concurrency. 
   - Value objects, DTO's etc. can be easily created.   - Value objects, DTO's etc. can be easily created.
-  - Properties can be public which removes need for getters without allowing state modification.+  - Properties can be public which removes the need for getters without allowing state modification.
   - (Please point it out more advantages)   - (Please point it out more advantages)
  
 **Cons** **Cons**
-  - (Please point it out more disadvantages)+  - Currently arrays on immutable properties are not supported.
  
  
Line 29: Line 29:
 ==== Immutable Class ==== ==== Immutable Class ====
  
-Class defined as immutable will imply immutability across all of it's properties by default. After object is constructor, it is not possible to modify state of object from any scope.+A class defined as immutable will imply immutability across all of its properties by default. After the object is constructed, it is not possible to modify the state of the object from any scope.
  
 <code php> <code php>
Line 46: Line 46:
 </code> </code>
  
-Changes to inheritance are made to add constraints when extending a immutable class, child class must also be immutable in order to to preserve immutability across whole object.+Changes to inheritance are made to add constraints when extending an immutable class - the child class must also be immutable in order to preserve immutability across the whole object.
  
 <code php> <code php>
Line 56: Line 56:
 ==== Immutable Properties ==== ==== Immutable Properties ====
  
-Classes have ability to enforce immutability to only subset of properties if needed, in that case immutability will be implied only on properties that are delared immutable.+Classes have the ability to enforce immutability to only a subset of properties if needed, in that case, immutability will be implied only on properties that are declared as immutable.
  
 <code php> <code php>
Line 71: Line 71:
  
  
-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, to preserve immutability, the object that is being assigned to the immutable property must also be immutable.
 <code php> <code php>
 immutable class Email{} immutable class Email{}
Line 84: Line 84:
 </code> </code>
  
-If immutable property of parent class is overridden in child class, it has to be declared as immutable. +Resources are not allowed to be assigned to immutable properties because of fact that resources by nature are not immutable. 
-Since focus of this RFC is on immutable objects, having static properties in immutable classes will result in compile error.+<code php> 
 +class File { 
 +  public immutable $handle; 
 + 
 +  public function __construct ($handle) { 
 +    $this->handle = $handle; 
 +  } 
 +} 
 + 
 +$file = new File(fopen('file.txt')); 
 +</code> 
 + 
 +Arrays are not allowed to be assigned to immutable properties.. 
 +<code php> 
 +class A { 
 +  public immutable $x; 
 + 
 +  public function __construct ($x) { 
 +    $this->x = $x; 
 +  } 
 +} 
 + 
 +$a = new A(['foo']); 
 +</code> 
 + 
 +If an immutable property of a parent class is overridden in a child class, it has to be declared as immutable. 
 +Since the focus of this RFC is immutable objects, having static properties in immutable classes will result in a compile error.
  
  
 ==== References ==== ==== References ====
  
-Assigning by references to immutable properties will result with error, otherwise object looses controll over properties and immutability can be broken.+Assigning by references to immutable properties will result in an error, otherwise the object loses control over properties, and immutability can be broken.
  
 <code php> <code php>
Line 108: Line 134:
 </code> </code>
  
 +==== Comparison ====
 +
 +Identity of immutable object is based on its value. So two immutable are identical if they are of the same type and contain same value.
 +
 +<code php>
 +immutable class Email {
 +  public $email;
 +
 +  public function __construct ($email) {
 +    // validation
 +
 +    $this->email = $email;
 +  }
 +}
 +
 +$email1 = new Email("foo@php.net");
 +$email2 = new Email("foo@php.net");
 +var_dump($email1 === $email2); // bool(true)
 +</code>
  
 ===== Examples ===== ===== Examples =====
-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 above example, changing getters and setters methods to public properties is optional. They simply don't need to be protected anymore, in fact, immutable class objects are deeply frozen with exceptions on write.
  
-Every example shows where internal object state is important. Any references to objects passed into immutable class constructor cannot be references to scalars or may be immutable class instances. That gives high guarantee you will keep internal state unchanged for all the time.+Every example shows where internal object state is important. Any references to objects passed into an immutable class constructor cannot be references to scalars or may be immutable class instances. That gives high guarantee you will keep internal state unchanged for all the time.
  
 ---- ----
Line 119: Line 164:
 ==== Money ==== ==== Money ====
  
-Money Pattern, defined by Martin Fowler and published in Patterns of Enterprise Application Architecture, is a great way to represent value-unit pairs. It is called Money Pattern because it emerged in a financial context.+Money Pattern, defined by Martin Fowler and published in Patterns of Enterprise Application Architecture, is a great way to represent value-unit pairs. It is called the Money Pattern because it emerged in a financial context.
  
 <code php> <code php>
Line 253: Line 298:
 </code> </code>
  
-There is no need for getters because internally immutable object if deeply frozen and none of his properties cannot be written anymore. All properties accepts scalar values or objects which implements immutable classes so there is high guarantee such Money object will keep his internal state untouched.+There is no need for getters because this internally immutable object is deeply frozen, and none of his properties cannot be written to anymore. All properties accept scalar values or objects which implement the immutable class, so there is high guarantee such Money object will keep its internal state untouched.
  
  
 ===== Backward Incompatible Changes ===== ===== Backward Incompatible Changes =====
  
-No backward incompatible changes.+No backwardly incompatible changes.
  
  
 ===== Proposed PHP Version(s) ===== ===== Proposed PHP Version(s) =====
  
- - PHP 7.2+ To be discussed.
  
 ===== RFC Impact ===== ===== RFC Impact =====
Line 294: Line 339:
 ===== Future Scope ===== ===== Future Scope =====
  
 +Add support for arrays on immutable properties.
 +Expand immutability to regular variables also.
  
 ===== Proposed Voting Choices ===== ===== Proposed Voting Choices =====
Line 301: Line 348:
  
 ===== Patches and Tests ===== ===== Patches and Tests =====
-[[https://github.com/php/php-src/compare/master...brzuchal:immutable]]+[[https://github.com/php/php-src/compare/master...smarijic:immutable-rfc]]
  
  
rfc/immutability.1480688649.txt.gz · Last modified: 2017/09/22 13:28 (external edit)

Page Tools