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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
