rfc:property_write_visibility

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:property_write_visibility [2020/06/29 14:10] – Adapt for feedback on syntax, propose alternative based on swift syntax andreromrfc:property_write_visibility [2020/07/07 07:33] (current) andrerom
Line 1: Line 1:
 ====== PHP RFC: Property write/set visibility ====== ====== PHP RFC: Property write/set visibility ======
-  * Version: 0.4.5+  * Version: 0.4.6
   * Date: 2020-06-29   * Date: 2020-06-29
   * Author: André Rømcke <andre.romcke+php@gmail.com>   * Author: André Rømcke <andre.romcke+php@gmail.com>
-  * Proposed PHP version: PHP 8.0+  * Proposed PHP version: PHP 8.1
   * Status: Under Discussion   * Status: Under Discussion
   * First Published at: http://wiki.php.net/rfc/readonly_and_immutable_properties   * First Published at: http://wiki.php.net/rfc/readonly_and_immutable_properties
Line 18: Line 18:
  
 <code php> <code php>
 +/**
 + * @property-read int $id
 + * @property-read string $name
 + */
 class User { class User {
     private int $id;     private int $id;
Line 91: Line 95:
 ===== Main differences to previous proposals ===== ===== Main differences to previous proposals =====
  
-This RFC is inspired by what was proposed on internals mailing list in "RFC Proposal - Attributes read/write visibility" by Amaury Bouchard, on 15 July 2012. The proposal was made as part of the ongoing discussions around [[rfc:readonly_properties|Readonly properties]] and [[rfc:propertygetsetsyntax-v1.2|Property Accessors Syntax]].+This RFC is inspired by what was proposed on internals mailing list in "RFC Proposal - Attributes read/write visibility" by Amaury Bouchard, on 15 July 2012. And the syntax and semantics found in [[https://docs.swift.org/swift-book/LanguageGuide/AccessControl.html#ID18|Swift]]
 + 
 +In both cases the purpose is to provide for a wider set of use cases.
  
 ==== Readonly ==== ==== Readonly ====
Line 97: Line 103:
 This RFC allows for among others semantics proposed in [[rfc:readonly_properties|Readonly properties]] (2014, Withdrawn), by setting read/get as ''public'' and write/set as ''protected''. This RFC allows for among others semantics proposed in [[rfc:readonly_properties|Readonly properties]] (2014, Withdrawn), by setting read/get as ''public'' and write/set as ''protected''.
  
 +This RFC does however **not** introduce any native readonly keyword/attribute which would be more readable, however this provides the underlying language concepts needed for introducing a Readonly attribute later.
  
 ==== Immutability ==== ==== Immutability ====
Line 134: Line 141:
          
     // Property is write-only in public and protected scope     // Property is write-only in public and protected scope
-    private:public string $newName;+    private:public string $newPassword;
  
     public function __construct(int $id, string $name) {     public function __construct(int $id, string $name) {
Line 158: Line 165:
          
     // Property is write-only in public and protected scope     // Property is write-only in public and protected scope
-    private public(set) string $newName;+    private public(set) string $newPassword;
  
     public function __construct(int $id, string $name) {     public function __construct(int $id, string $name) {
Line 172: Line 179:
  
 ==== References ==== ==== 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 212: Line 218:
 ==== Why not a Readonly keyword/attribute ==== ==== Why not a Readonly keyword/attribute ====
  
-Several comments are pointing out that ''readonly'', ''writeonly'', ''immutable'' keywords/attributes would be more readable, and this is true. However what is proposed here is made in such a way that for instance a ''Readonly'' attribute can be introduced more easily in the future, given attributes themselves currently can't define language features.+Several comments are pointing out that ''readonly'', ''writeonly'', ''immutable'' keywords/attributes would be more readable, and this is true. However what is proposed here is made in such a way that for instance a ''Readonly'' attribute can be introduced more easily in the future.
  
-Additionally 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 solved.+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 224: Line 230:
 ===== Proposed PHP Version(s) ===== ===== Proposed PHP Version(s) =====
  
-Next PHP version, 8.suggested.+Next PHP version, 8.suggested.
  
  
rfc/property_write_visibility.1593439827.txt.gz · Last modified: 2020/06/29 14:10 by andrerom