rfc:final_properties

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:final_properties [2020/02/18 20:29] kocsismaterfc:final_properties [2020/02/18 23:29] (current) kocsismate
Line 11: Line 11:
  
 ===== Proposal ===== ===== Proposal =====
-"Write-once" properties in PHP (the actual keyword is to be decided) could be initialized either by an explicit default value, or by assigning a value to them. Unlike to ''final'' properties in Java, this RFC proposes to allow the initialization of object properties after object construction. The main purpose of this behaviour is to make lazy loading possible - which is an important aspect for many PHP applications. In addition to object properties, class properties can also use the modifier in question with the same restrictions.+"Write-once" properties in PHP (the actual keyword is to be decided) could be initialized either by an explicit default value, or by assigning a value to them. Unlike to ''final'' properties in Java, this RFC proposes to allow the initialization of object properties after object construction. The main purpose of this approach is to make lazy loading possible - which is an important aspect for many PHP applications. In addition to object properties, class properties can also use the modifier in question with the same rules.
  
-As soon as initialization is done, any other attempt to assign a new value to "write-once" properties would result in an exception as it can be seen below:+As soon as initialization is done, any other attempt to assign a value to "write-once" properties results in an exception. Besides assignment, the increment, decrement, and unset operations are also forbidden. As arrays are an immutable data structure in PHP, any attempt to mutate a property of array type (adding/removing/changing items) is forbidden. However, properties of object or resource types still remain mutable internally. In order to avoid problems with references, references on "write-once" properties are disabled as well.
  
 <code php> <code php>
Line 19: Line 19:
 class Foo class Foo
 { {
-    final public int $a; +    <keyword> public int $a = 1
-    final public string $b; +    <keyword> public string $b; 
-    final public array $c = ["foo"]; +    <keyword> public array $c = ["foo"]; 
-    final public stdclass $d;+    <keyword> public object $d;
  
     public function __construct()     public function __construct()
     {     {
-        $this->1; +        $this->"foo";
-        $this->d = new stdclass();+
     }     }
 } }
Line 34: Line 33:
  
 $foo->a = 2; // EXCEPTION: property a has already been initialized $foo->a = 2; // EXCEPTION: property a has already been initialized
-$foo->b = ""; // SUCCESS +$foo->b = "bar"; // EXCEPTION: property b has already been initialized 
-$foo->= []; // EXCEPTION: property c has already been initialized +$foo->a++; // EXCEPTION: incrementing/decrementing is forbidden 
-$foo->c[] = "bar"; // EXCEPTION: arrays are by-value +unset($foo->c); // EXCEPTION: unsetting is forbidden 
-$foo->d->foo = "foo"; // SUCCESS: it's not an assignment+$foo->c[] = "bar"; // EXCEPTION: arrays can't be modified 
 + 
 +$foo->d = new Foo(); // SUCCESS: property d hasn't been initialized before 
 +$foo->d->foo = "foo"; // SUCCESS: objects are treated by-reference
  
 </code> </code>
  
-As untyped properties have an implicit default value (''null'') in the absense of an explicit one, their usefulness would be very limited. In order to avoid the introduction or unintiutive workarounds, this RFC proposes to disable the "final" property modifier for them. Contrarily to untyped properties, typed properties are in uninitialized state by default, so they play well with the write-once semantics introduced by "final" properties. In order to be safe from problems with references, references on "final" properties are disabled as well.+As untyped properties have an implicit default value (''null'') in the absense of an explicit one, their usefulness would be very limited. In order to avoid the introduction or unintiutive workarounds, this RFC proposes to disable the property modifier in question for them. Contrarily to untyped properties, typed properties are in uninitialized state by default, so they play well with the write-once semantics. 
 + 
 +===== Discussion ===== 
 + 
 +==== Approach ====
  
-===== Open questions ===== +==== Name choice ==== 
-As there is no consensus about the name of the modifier, I'd like to put it to vote. You can find below the ideas that came up during discussion along with their pros/cons:+As there is no consensus about the name of the modifier, I'd like to put it to vote. You can find below the ideas that came up during discussion along with some pros/cons:
  
-  * ''final'': It would be a better fit for a modifier that prevents a property to be overridden (just like how it works for classes and methods) +  * ''final'': It would be a better fit for a modifier that prevents a property to be overridden (just like how ''final'' works in case of classes and methods) 
-  * ''immutable'': Actually, this name is a lie because the usage of mutable data structures are not restricted (objects, resources) +  * ''immutable'': Actually, this name is a lie since the usage of mutable data structures are not restricted (objects, resources) at all 
-  * ''readonly'': This name can also lie (in case of lazy initialization) because the proposed modifier would actually work according to "write-once" semantics. The ''readonly'' modifier can be familiar for those who use C# though +  * ''readonly'': Although it' a familiar term from C#, this name also lies as the proposed modifier actually works according to "write-once" semantics 
-  * ''writeonce'': it's the most clear and most descriptive name among all, but it doesn't sound familiar at all +  * ''writeonce'': It's the most clear and most descriptive name among all, but it doesn't sound familiar at all 
-  * ''locked'': it's a more abstract, less clear name for the feature, but at least it's not a lie+  * ''locked'': It's a more abstract, less clear name for the feature, but at least it doesn'lie
   * ''sealed'': It has the same properties as ''locked'', and this keyword is also used in C# (similarly to ''final'' in PHP)   * ''sealed'': It has the same properties as ''locked'', and this keyword is also used in C# (similarly to ''final'' in PHP)
  
-That saidI'd like to propose "locked", "sealed", and "writeonce" as voting choices about the name of the feature.+Considering the above, "locked", "sealed", and "writeonce" is going to be proposed as voting choices of the decision about the keyword.
  
 ===== Backward Incompatible Changes ===== ===== Backward Incompatible Changes =====
Line 59: Line 65:
  
 ===== Future Scope ===== ===== Future Scope =====
-Adding support for "final" properties would lay the groundwork for immutable objects - for which I'm going to create a proposal if the current RFC is accepted.+Adding support for "write-once" properties would lay the groundwork for immutable objects - for which I'm going to create a proposal should the current RFC be accepted.
  
 ===== Proposed Voting Choices ===== ===== Proposed Voting Choices =====
-The primary vote ("Do you want to add support for the new property modifier?") requires 2/3 majority, while the secondary one ("Which keyword to use"?) requires a simple majority.+The primary vote ("Do you want to add support for the proposed property modifier?") requires 2/3 majority, while the secondary one ("Which keyword to use"?) requires a simple majority.
  
 ===== References ===== ===== References =====
 Prior RFC proposing the introduction of ''immutable'' properties: https://wiki.php.net/rfc/immutability Prior RFC proposing the introduction of ''immutable'' properties: https://wiki.php.net/rfc/immutability
  
rfc/final_properties.1582057765.txt.gz · Last modified: 2020/02/18 20:29 by kocsismate