Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78440
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain seld.be designates 209.85.212.178 as permitted sender)
Message-ID: <54506D20.3010402@seld.be>
Date: Wed, 29 Oct 2014 04:29:20 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <6E04B9BE-854E-4112-8C74-7D90BD8BFE95@ajf.me> <544D48A3.6070905@gmail.com> <572FEBD1-99A8-4788-83F9-D99E470FB16D@ajf.me> <544F4321.8040302@seld.be> <E87E48F1-5D79-4C6A-9368-C0A3CA35501F@ajf.me> <544FA716.2030508@gmail.com> <ABF60DD2-24F7-4016-85B8-8D8585442BC1@ajf.me>
In-Reply-To: <ABF60DD2-24F7-4016-85B8-8D8585442BC1@ajf.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Readonly Properties
From: j.boggiano@seld.be (Jordi Boggiano)

On 28/10/2014 15:08, Andrea Faulds wrote:
>
>> On 28 Oct 2014, at 14:24, Rowan Collins <rowan.collins@gmail.com> wrote:
>>
>> Andrea Faulds wrote on 28/10/2014 14:08:
>>>>> On 28 Oct 2014, at 07:17, Jordi Boggiano<j.boggiano@seld.be>  wrote:
>>>>>
>>>>> I like it, except for the fact that if you add a custom getter to a property suddenly it becomes readonly unless you remember to add "; set" to the end of the block, right?
>>> Well, no. If you choose to specify getters and setters, and only specify a setter, of course it is read-only. It doesn’t make sense to have a getter and no setter and yet expect a property to be writeable.
>>>
>>
>> I think the problem is that the get and set annotations are serving multiple purposes - to change the visibility, to define custom accessor/mutator code, but also to declare whether certain actions are possible at all. Since the default is for the property to be readable and writable, the fact that adding "{ get; }" makes it readonly isn't immediately intuitive, although it does makes sense once you think about it.
>
> Hmm. Perhaps we need this, then:
>
> public $foobar; // public read, private write
> public/private $foobar; // public read, private write
> public readonly $foobar; // public read, not writeable at all
>
> This then confined set/get entirely to implementation details. A read-only property would be denoted by readonly.
>
> With the last one, you can only have get, for the first two, you must have both get and set.
>
> Does that work? Seems pretty good to me.

Yup that's definitely better than having the readonly flag in the {} 
block as I had it.

I'd however say that it should be possible to define a writable property 
with only a getter and then the setter would implicitly be created. 
Since readonly is the way to define writability why should I have to 
specify a setter (even a default empty one) if none is needed?

P.S: Don't want to open pandora's box, but we could also have writeonly 
for completeness perhaps. I don't really see the use case at all though 
(immutability sure, mutant bottomless pit objects not so much:).

Cheers

-- 
Jordi Boggiano
@seldaek - http://nelm.io/jordi