Re: [RFC] Readonly Properties
| From: | Rowan Collins | Date: | Sun, 26 Oct 2014 19:16:51 +0000 |
| Subject: | Re: [RFC] Readonly Properties | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-78352@lists.php.net to get a copy of this message | ||
On 24/10/2014 00:36, Andrea Faulds wrote:
Good evening once again, Here’s another RFC: https://wiki.php.net/rfc/readonly_properties It proposes, with a working implementation, a modifier for properties that makes them readable and writeable from different scopes. Since I am a big proponent of including specification patches in new RFCs, I have decided to put my money (or rather, time) where my mouth is and I have actually written a specification patch before writing an RFC. I would love to see this become the new standard for RFCs affecting the language. If you are curious at all about the behaviour, I suggest perusing the fairly comprehensive set of twelve tests included in the main patch to php-src. Thanks!I just had a thought on both the naming and future-proofing concerns of this proposal: what about pre-emptively reserving the skeleton of the syntax needed for accessors, without actually implementing them? For instance, one of the (confusingly many) syntaxes allowed by https://wiki.php.net/rfc/propertygetsetsyntax-v1.2 would have been this: private $foo { public get; protected set; } In that instance, this was seen as short-hand for the default "proxy method", but the effect is to modify the visibility of the property without any extra behaviour. If we remove the requirement to specify both get and set if the guard clause is added, we get a simple syntax that covers the two cases the RFC's "readonly" keyword does, plus one more: // Current RFC public readonly $foo; // read public, write protected protected readonly $foo; // read protected, write private // With only "set" keyword public $foo { protected set; } protected $foo { private set; } public $foo { private set; } // read public, write private // With only "get" keyword protected $foo { public get; } private $foo { protected get; } private $foo { public get; } // With both keywords, since "var" has been undeprecated var $foo { public get; protected set; } var $foo { protected get; private set; } var $foo { public get; private set; } This syntax does imply other combinations like "private get; public set;" (effectively "write-only" from certain scopes), which may complicate matters somewhat. To keep things simple, we could simply enforce a rule at compile time that "read visibility must not be more restrictive than write visibility". This gets rid of the ambiguity of the "readonly" keyword, and makes the behaviour of "read protected, write private" much more obvious. It also opens the door to syntax for accessors without placing much restriction on how they could work... // Forwards compatible to all these and more... var $foo { public get { return $this->bar * 10; } private set; } var $foo { public get() { return $this->bar * 10; } private set; } var $foo { public get => $this->bar * 10; private set; } var $foo { public get: existingMethod; private set; } -- Rowan Collins [IMSoP]