Differences

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

--- rfc:final_properties [2020/02/18 09:37] – created kocsismate
+++ rfc:final_properties [2020/02/18 20:29] – kocsismate
@@ Line 1: / Line 1: @@
-====== PHP RFC: Your Title Here ======
+====== PHP RFC: Write-Once Properties ======
   * Version: 0.1
   * Date: 2020-02-18
@@ Line 8: / Line 8: @@
 ===== Introduction =====
-This RFC proposes to add support for a new property modifier that would allow properties to be initialized, but not modified afterwards (including incrementing/decrementing, unsetting them). For example, Java and C# also have a similar - but not exactly the same - concept.
+This RFC proposes to add support for a new property modifier that would allow properties to be initialized, but not modified afterwards. This feature would be useful in situations where one wants to guarantee that a property remains the same for the lifetime of an object - which is usually the case for Value Objects or Data Transfer Objects. Other languages, like Java and C# also have similar - but not exactly the same - concepts for a long time (''final'' and ''readonly'' respectively).
 ===== Proposal =====
-"Final" 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 is to make lazy loading possible - which is an important aspect for many PHP applications. Additionally to object properties, class properties can also use the "final" modifier 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 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.
-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 for 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 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:
+<code php>
+class Foo
+{
+    final public int $a;
+    final public string $b;
+    final public array $c = ["foo"];
+    final public stdclass $d;
+    public function __construct()
+    {
+        $this->a = 1;
+        $this->d = new stdclass();
+    }
+}
+$foo = new Foo();
+$foo->a = 2;		// EXCEPTION: property a has already been initialized
+$foo->b = "";		// SUCCESS
+$foo->c = [];		// EXCEPTION: property c has already been initialized
+$foo->c[] = "bar";	// EXCEPTION: arrays are by-value
+$foo->d->foo = "foo";	// SUCCESS: it's not an assignment
+</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.
 ===== Open questions =====
-As there is no consensus about the name of the modifier, I'd like to put it to vote. You can find below the pros/cons for/against each of them that came up during discussion: (TBD)
+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:
+  * ''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)
+  * ''immutable'': Actually, this name is a lie because the usage of mutable data structures are not restricted (objects, resources)
+  * ''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
+  * ''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
+  * ''sealed'': It has the same properties as ''locked'', and this keyword is also used in C# (similarly to ''final'' in PHP)
-  * ''immutable'':
+That said, I'd like to propose "locked", "sealed", and "writeonce" as voting choices about the name of the feature.
-  * ''final'':
-  * ''locked'':
-  * ''sealed'':
-  * ''readonly'':
-  * ''writeonce'':
 ===== Backward Incompatible Changes =====
-There are no backward incompatible changes in this proposal except for the fact that "writeonce", "locked", "sealed", or "final" would become a reserved keyword depending on the outcome of the secondary vote.
+There are no backward incompatible changes in this proposal except for the fact that "locked", "sealed", or "writeonce" would become a reserved keyword depending on the outcome of the secondary vote.
 ===== Future Scope =====

Differences

Page Tools