Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78352
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.173 as permitted sender)
Message-ID: <544D48A3.6070905@gmail.com>
Date: Sun, 26 Oct 2014 19:16:51 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <6E04B9BE-854E-4112-8C74-7D90BD8BFE95@ajf.me>
In-Reply-To: <6E04B9BE-854E-4112-8C74-7D90BD8BFE95@ajf.me>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Readonly Properties
From: rowan.collins@gmail.com (Rowan Collins)

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]