| Both sides previous revisionPrevious revision | |
| rfc:final_properties [2020/02/18 22:30] – kocsismate | rfc:final_properties [2020/02/18 23:29] (current) – kocsismate |
|---|
| |
| ===== 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 rules. | "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 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, since objects or resources are treated by-reference, they can be | 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> |
| </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 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. In order to be safe from problems with references, references on "write-once" 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. |
| |
| ===== Open questions ===== | ===== Discussion ===== |
| | |
| | ==== Approach ==== |
| | |
| | ==== 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 some 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: |
| |
| * ''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) |
| |
| Considering the above, I'd like to propose "locked", "sealed", and "writeonce" as voting choices of the decision about the keyword. | 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 ===== |