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
Last revisionBoth sides next 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/04 10:05] – 8.1 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.0 or 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.0 suggested.+Next PHP version, 8.0 or more realistically 8.1 suggested.
  
  
rfc/property_write_visibility.txt · Last modified: 2020/07/07 07:33 by andrerom

Page Tools