Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78335
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain seld.be designates 74.125.82.45 as permitted sender)
Message-ID: <544CCD5A.6070404@seld.be>
Date: Sun, 26 Oct 2014 10:30:50 +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: Andrea Faulds <ajf@ajf.me>, Pierre Joye <pierre.php@gmail.com>
CC: PHP Internals <internals@lists.php.net>
References: <6E04B9BE-854E-4112-8C74-7D90BD8BFE95@ajf.me> <544A1BF5.3090708@seld.be> <D4E63CE5-2FD6-49ED-BF78-AFD3D479A078@ajf.me>
In-Reply-To: <D4E63CE5-2FD6-49ED-BF78-AFD3D479A078@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 24/10/2014 12:54, Andrea Faulds wrote:
>
>> On 24 Oct 2014, at 10:29, Jordi Boggiano <j.boggiano@seld.be> wrote:
>>
>> Thanks for the work (again). It's an interesting small idea but I'd much prefer revisiting the original getter/setter RFC [1] which had a majority but just fell short of the 66% mark.
>>
>> This RFC only implements parts of the getter/setter functionality (readonly properties) but it does not address the fact that sometimes you want to add logic to a setter or a getter and if you don't have language level getters/setters you end up having to change the interface of the object from a public property to a getFoo/setFoo pair.
>>
>> This leads to everyone having getFoo/setFoo by default just to avoid interface changes or mixed interfaces of public properties and setFoo.
>
>>
>> On 24 Oct 2014, at 10:34, Pierre Joye <pierre.php@gmail.com> wrote:
>>
>> As much i really like the idea to have better properties management in
>> PHP I see this RFC as an attempt to solve only part of the problem
>> while dropping most of the other ideas implemented in the past RFCs.
>> My take on that is that some will vote no, or won't like the idea of
>> adding anything in this area. Making compromises and implement partial
>> solutions will only delay the implementation of the complete solution.
>>
>> Many of us agree that __get/__set is a pain to deal with.The need of
>> readonly, writeonly or properties with some logic to define or get a
>> value is a lond due need. Many other languages support that out of the
>> box since long already. Past RFCs, like the c# one, proposed that. I
>> would rather focus on trying to find an acceptable syntax and
>> implementation instead of doing baby steps like that. Baby steps work
>> very well for scalar type hinting, solving one issue after another,
>> etc. But for properties we are at the risk of hainvg a serie of
>> separate RFCs solving the properties management problems in different
>> ways bringing even more troubles and inconsistencies.
>
> I think I might be misunderstood, here. While getters and setters can
> do this, and I’m very much in favour of also reviving a simplified
> version of the getter/setter RFC (previous one was way too complex),
> I don’t see this as partly implementing them/baby steps/etc. I fact,
> I think readonly properties could work together with
> getters/setters.

Fair enough, thanks for the clarification. It also sounds good to have 
very simple getter/setters when needed and simple properties + 
eventually readonly otherwise. issetters/unsetters aren't extremely needed.

Cheers

-- 
Jordi Boggiano
@seldaek - http://nelm.io/jordi