rfc:property_write_visibility
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
rfc:property_write_visibility [2020/06/28 19:17] – Simplify reflection and add link to Swift syntax for discussion andrerom | rfc:property_write_visibility [2020/06/30 20:00] – Use newPassword as it's more valid as example of writeOnly andrerom | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== PHP RFC: Property write visibility ====== | + | ====== PHP RFC: Property write/set visibility ====== |
- | * Version: 0.4 | + | * Version: 0.4.5 |
- | * Date: 2020-06-25 | + | * Date: 2020-06-29 |
* Author: André Rømcke < | * Author: André Rømcke < | ||
* Proposed PHP version: PHP 8.0 | * Proposed PHP version: PHP 8.0 | ||
- | * Status: | + | * Status: |
* First Published at: http:// | * First Published at: http:// | ||
- | * Discussion: https:// | + | * Discussion: https:// |
===== Introduction ===== | ===== Introduction ===== | ||
- | With the introduction of [[rfc: | + | With the introduction of [[rfc: |
- | This RFC resolves this issue by proposing to allow classes to optionally declare property write visibility, disconnected from read visibility. | + | This RFC resolves this issue by proposing to allow classes to optionally declare property write/set visibility, disconnected from read/get visibility. |
- | Under this RFC, code like | + | Under this RFC, code like the following using magic methods: |
<code php> | <code php> | ||
Line 57: | Line 57: | ||
</ | </ | ||
- | might be written as | + | might be written as //(Language syntax Option A)//: |
<code php> | <code php> | ||
Line 70: | Line 70: | ||
} | } | ||
</ | </ | ||
+ | |||
+ | |||
+ | or //(Language Syntax Option B)//: | ||
+ | |||
+ | <code php> | ||
+ | class User { | ||
+ | public private(set) int $id; | ||
+ | public protected(set) string $name; | ||
+ | |||
+ | public function __construct(int $id, string $name) { | ||
+ | $this-> | ||
+ | $this-> | ||
+ | } | ||
+ | } | ||
+ | </ | ||
+ | |||
Line 75: | Line 91: | ||
===== Main differences to previous proposals ===== | ===== Main differences to previous proposals ===== | ||
- | This RFC is inspired by past RFCs and the discussions that happened around them. Especially credit to [[rfc: | + | This RFC is inspired by what was proposed on internals mailing list in "RFC Proposal - Attributes read/write visibility" |
+ | |||
+ | In both cases the purpose is to provide for a wider set of use cases. | ||
==== Readonly ==== | ==== Readonly ==== | ||
- | This RFC allows for among others semantics proposed in [[rfc: | + | This RFC allows for among others semantics proposed in [[rfc: |
+ | This RFC does however **not** introduce any native readonly keyword/ | ||
==== Immutability ==== | ==== Immutability ==== | ||
- | This RFC allows | + | This RFC allows to // |
+ | |||
+ | This RFC does however **not** introduce any immutable knowhow in the language which JIT can optimize for, however the features here can be built upon for a native immutable keyword/ | ||
+ | |||
+ | |||
+ | ==== Write once ==== | ||
This RFC does __not__ align with the semantics of the recent [[rfc: | This RFC does __not__ align with the semantics of the recent [[rfc: | ||
Line 93: | Line 117: | ||
This RFC does not try to solve as wide use case as the different iterations of [[rfc: | This RFC does not try to solve as wide use case as the different iterations of [[rfc: | ||
- | However | + | However what being proposed here is aligned to make sure Accessors can cleanly be added later. |
===== Proposal ===== | ===== Proposal ===== | ||
- | This proposal adds support for enforced write visibility checks for declared properties. The following example illustrates the basic syntax: | + | This proposal adds support for enforced write/set visibility checks for declared properties. |
+ | |||
+ | ==== Language syntax A: " | ||
+ | |||
+ | The following example illustrates the basic syntax: | ||
<code php> | <code php> | ||
Line 109: | Line 137: | ||
| | ||
// Property is write-only in public and protected scope | // Property is write-only in public and protected scope | ||
- | private: | + | private: |
public function __construct(int $id, string $name) { | public function __construct(int $id, string $name) { | ||
Line 118: | Line 146: | ||
</ | </ | ||
- | The format is ''< | + | The format is ''< |
- | ==== References | + | ==== Language syntax B: " |
+ | The following example illustrates the basic syntax: | ||
+ | |||
+ | <code php> | ||
+ | class User { | ||
+ | // Property is readonly in protected and public scope | ||
+ | public private(set) int $id; | ||
+ | |||
+ | // Property is readonly in public scope | ||
+ | public protected(set) string $name; | ||
+ | | ||
+ | // Property is write-only in public and protected scope | ||
+ | private public(set) string $newPassword; | ||
+ | |||
+ | public function __construct(int $id, string $name) { | ||
+ | $this-> | ||
+ | $this-> | ||
+ | } | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | The format in this option is taken from [[https:// | ||
+ | |||
+ | Like in the other syntax proposal, if set visibility is not specified, as before the global visibility will define both read/get and write/set visibility. | ||
+ | |||
+ | ==== References ==== | ||
Attempting to pass a property value outside of allowed writable scope as a reference, results in an error. | Attempting to pass a property value outside of allowed writable scope as a reference, results in an error. | ||
Line 128: | Line 181: | ||
==== Reflection ==== | ==== Reflection ==== | ||
- | When using reflection, methods such as '' | + | When using reflection, methods such as '' |
In order to avoid backwards compatibility issue, the following methods will get updated behavior: | In order to avoid backwards compatibility issue, the following methods will get updated behavior: | ||
- | - '' | + | * '' |
- | - '' | + | |
- | - '' | + | |
The following methods needs to be added to detect different read vs write visibility: | The following methods needs to be added to detect different read vs write visibility: | ||
- | - '' | + | * '' |
- | - '' | + | |
- | - '' | + | |
- | - '' | + | * '' |
- | - '' | + | |
- | - '' | + | |
Line 155: | Line 208: | ||
==== Language Syntax ==== | ==== Language Syntax ==== | ||
- | The format being proposed here ''< | + | The format |
- | If we where to just have two separate visibility keywords | + | Plain " |
- | One other alternative | + | ==== Why not a Readonly keyword/ |
+ | |||
+ | Several comments are pointing out that '' | ||
+ | |||
+ | AS in, if the language don't have a concept for write/set property visibility, then we'll end up with having to introduce reflection api that are tied in to the keyword/attribute introduced instead, as opposed to the underlying concept. | ||
Line 191: | Line 248: | ||
===== References ===== | ===== References ===== | ||
- | * [[https:// | + | * [[https:// |
* [[https:// | * [[https:// | ||
* [[https:// | * [[https:// | ||
Line 205: | Line 262: | ||
Significant changes to the RFC are noted here. | Significant changes to the RFC are noted here. | ||
+ | |||
+ | * 2020-06-29 Adapt for initial feedback, add syntax proposal aligned with Swift | ||
* 2020-06-28 Simplify Reflection API proposal, add syntax alternatives for discussion | * 2020-06-28 Simplify Reflection API proposal, add syntax alternatives for discussion | ||
* 2020-06-25 Focus on write visibility proposal | * 2020-06-25 Focus on write visibility proposal | ||
* 2020-06-20 Initial early draft to get feedback on direction between visibility, readonly/ | * 2020-06-20 Initial early draft to get feedback on direction between visibility, readonly/ |
rfc/property_write_visibility.txt · Last modified: 2020/07/07 07:33 by andrerom