rfc:write_once_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
Next revisionBoth sides next revision
rfc:write_once_properties [2020/03/15 22:14] – kocsismaterfc:write_once_properties [2020/03/17 10:13] – kocsismate
Line 4: Line 4:
   * Author: Máté Kocsis <kocsismate@php.net>   * Author: Máté Kocsis <kocsismate@php.net>
   * Target Version: PHP 8.0   * Target Version: PHP 8.0
-  * Status: Under Discussion+  * Status: Voting
   * Implementation: https://github.com/php/php-src/pull/5186   * Implementation: https://github.com/php/php-src/pull/5186
  
Line 14: Line 14:
 ==== Run-time behaviour ==== ==== Run-time behaviour ====
  
-"Write-once" properties in PHP (the actual keyword is to be decided) could be initialized either by an explicit default value, or by an assignment operation. Contrary to how ''final'' properties in Java work, this RFC proposes to allow the initialization of object properties after object construction. The main purpose of choosing 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.+"Write-once" properties in PHP (the actual keyword is to be decided) could be initialized by an assignment operation. Contrary to how ''final'' properties in Java work, this RFC proposes to allow the initialization of object properties after object construction. The main purpose of choosing 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 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 that have an object type still remain mutable internally (see example below). In order to avoid possible problems, references on "write-once" properties are forbidden as well. 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 that have an object type still remain mutable internally (see example below). In order to avoid possible problems, references on "write-once" properties are forbidden as well.
Line 22: Line 22:
 class Foo class Foo
 { {
-    <keyword> public int $a = 1; +    <keyword> public int $a; 
-    <keyword> public string $b; +    <keyword> public array $b; 
-    <keyword> public array $c = ["foo"]; +    <keyword> public object $c;
-    <keyword> public object $d;+
  
     public function __construct()     public function __construct()
     {     {
-        $this->b = "foo";+        $this->a = 1; 
 +        $this->b = ["foo"];
     }     }
 } }
Line 36: Line 36:
  
 $foo->a = 2; // EXCEPTION: property a has already been initialized $foo->a = 2; // EXCEPTION: property a has already been initialized
-$foo->b = "bar"; // EXCEPTION: property b has already been initialized 
 $foo->a++; // EXCEPTION: incrementing/decrementing is forbidden $foo->a++; // EXCEPTION: incrementing/decrementing is forbidden
-unset($foo->c); // EXCEPTION: unsetting is forbidden +unset($foo->b); // EXCEPTION: unsetting is forbidden 
-$foo->c[] = "bar"; // EXCEPTION: array values can't be modified +$foo->b[] = "bar"; // EXCEPTION: array values can't be modified 
-next($foo->c); // EXCEPTION: internal pointer of arrays can't be modified as well +next($foo->b); // EXCEPTION: internal pointer of arrays can't be modified as well 
-$var = &$this->c; // EXCEPTION: reference isn't allowed +$var = &$this->b; // EXCEPTION: reference isn't allowed 
-$this->c; = &$var; // EXCEPTION: reference isn't allowed+$this->b; = &$var; // EXCEPTION: reference isn't allowed
  
-key($foo->c); // SUCCESS: internal pointer of arrays is possible to read +key($foo->b); // SUCCESS: internal pointer of arrays is possible to read 
-$foo->d = new Foo(); // SUCCESS: property d hasn't been initialized before +$foo->c = new stdClass(); // SUCCESS: property c hasn't been initialized before 
-$foo->d->foo = "foo"; // SUCCESS: objects are still mutable internally+$foo->c->foo = "foo"; // SUCCESS: objects are still mutable internally
  
 </code> </code>
Line 54: Line 53:
 ==== Compile-type restrictions ==== ==== Compile-type restrictions ====
  
-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 of 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.+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 of 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 (meaning, they don't have a value yet), so they play well with the write-once semantics.
  
 This choice has a slightly inconvenient implication of not being able to use "write-once" properties together with resources - since PHP doesn't have the ''resource'' type declaration. Currently, a possible workaround is to wrap resources in objects, but another way to solve the issue could be provided from PHP's side by adding support for a ''mixed'' type. This choice has a slightly inconvenient implication of not being able to use "write-once" properties together with resources - since PHP doesn't have the ''resource'' type declaration. Currently, a possible workaround is to wrap resources in objects, but another way to solve the issue could be provided from PHP's side by adding support for a ''mixed'' type.
  
-Furthermore, the introduction of "write-once" properties impose slight changes to property variance validation. Namely, "write-once" properties must not override "non-write-once" properties because the parent class expects them to be mutable. That's why the following example results in a compilation error:+Another restriction of "write-once" properties is that they can't have a default value. Thus, the following syntax is forbidden: 
 + 
 +<code php> 
 + 
 +class Foo { 
 +    public int $a = 0; 
 +} 
 + 
 +</code> 
 + 
 +Instead, property ''$a'' should be initialized via an assignment either in the constructor or somewhere else. The purpose of this restriction is to avoid offering two syntaxes for declaring class constants as well as keeping our freedom to add new features to PHP that would otherwise have the possibility to interfere with the semantics of default values of "write-once" properties. 
 + 
 + 
 +Furthermore, the introduction of "write-once" properties impose slight changes to property variance validation. Namely, "write-once" properties must not override regular properties because the parent class expects them to be mutable. That's why the following example results in a compilation error:
  
 <code php> <code php>
Line 72: Line 84:
 </code> </code>
  
-However, "non-write-once" properties can override "write-once" properties like below:+However, regular properties can override "write-once" properties like below:
  
 <code php> <code php>
Line 88: Line 100:
 ==== Serialization ==== ==== Serialization ====
  
-"Write-once" properties can be serialized just like other properties. However, some new restriction will apply to them: +"Write-once" properties can be serialized just like other properties. However, a new rule will apply to them: malformed serialized data which sets a "write-once" property multiple times throws an exception.
- +
-  * Malformed serialized data which sets a "write-once" property twice throws an exception +
-  * Properties that have a default value are overwritten by the serialized value of the property+
  
 ==== Reflection ==== ==== Reflection ====
Line 125: Line 134:
  
 ===== Future Scope ===== ===== Future Scope =====
-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. I also plan to address the problem with cloning mentioned in the proposal section.+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. I also plan to address the problem with cloning mentioned in the "Proposal" section. 
 + 
 +Additionally, as mentioned in the "Compile-Type Restrictions" section, adding support for the ''mixed'' type would make it possible to use "write-once" properties together with resources. Besides this, we could allow the definition of default values later on as soon as we have a good use-case for them. 
 + 
 +Finally, "write-once" properties could in principle support covariance. That is, a subclass would be allowed to tighten the property type that is inherited from the parent class, while other properties must stay invariant. All this would be possible because of the quasi-immutable nature of "write-once" properties: they are generally expected to be assigned to only once, in the constructor - which is exempt from LSP checks. There is a gotcha though: in practice, "write-once" properties could be written from places other than the constructor. Although there might not be many practical use-cases for it, the infamous setter injection is certainly one (as shown at https://3v4l.org/DQ3To), in which case property covariance would be a problem. 
 + 
 +===== Vote ===== 
 + 
 +The vote starts on 2020-03-17 and ends on 2020-03-31. The primary vote requires 2/3, while the secondary one requires a simple majority to be accepted.
  
-Additionally, "write-once" properties could in principle support covariance. That is, a subclass would be allowed to tighten the property type that is inherited from the parent class, while other properties must stay invariant. All this would be possible because of the quasi-immutable nature of "write-once" properties: they are generally expected to be assigned to only once, in the constructor - which is exempt from LSP checks. There is gotcha though: in practice, "write-once" properties could be written from places other than the constructor. Although there might not be many practical use-cases for it, the infamous setter injection is certainly one (as shown at https://3v4l.org/DQ3To), in which case property covariance would be a problem.+<doodle title="Do you want to add support for write-once properties?" auth="kocsismate" voteType="single" closed="false"> 
 +   * Yes 
 +   * No 
 +</doodle>
  
-Finally, as mentioned in the "Compile-Type Restrictions" section, adding support for the ''mixed'' type would make it possible to use "write-once"  properties together with resources.+----
  
-===== Proposed Voting Choices ===== +<doodle title="Which keyword to use?" auth="kocsismate" voteType="single" closed="false"> 
-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.+   * Yes 
 +   * No 
 +</doodle>
  
 ===== References ===== ===== References =====
 Prior RFC proposing ''immutable'' properties: https://wiki.php.net/rfc/immutability Prior RFC proposing ''immutable'' properties: https://wiki.php.net/rfc/immutability
  
rfc/write_once_properties.txt · Last modified: 2020/03/31 07:51 by kocsismate

Page Tools