Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78302
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.213.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEZPtU7ehi6zgsGQz47dXGyX-Sgeo0ijfEfh4=LAU5tY90sFkw@mail.gmail.com>
References: <6E04B9BE-854E-4112-8C74-7D90BD8BFE95@ajf.me>
	<CAEZPtU7ehi6zgsGQz47dXGyX-Sgeo0ijfEfh4=LAU5tY90sFkw@mail.gmail.com>
Date: Fri, 24 Oct 2014 14:12:00 +0300
Message-ID: <CAPhkiZwysNGJoUhyrLMxeJk7c17gxK4qLJKP2A+-V0q-Dex8Dw@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: Andrea Faulds <ajf@ajf.me>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Readonly Properties
From: narf@devilix.net (Andrey Andreev)

Hi,

On Fri, Oct 24, 2014 at 12:34 PM, Pierre Joye <pierre.php@gmail.com> wrote:
> hi Andrea,
>
> On Fri, Oct 24, 2014 at 6:36 AM, Andrea Faulds <ajf@ajf.me> wrote:
>> Good evening once again,
>>
>> Here=E2=80=99s another RFC: https://wiki.php.net/rfc/readonly_properties
>>
>> It proposes, with a working implementation, a modifier for properties th=
at makes them readable and writeable from different scopes.
>>
>> Since I am a big proponent of including specification patches in new RFC=
s, 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 fa=
irly comprehensive set of twelve tests included in the main patch to php-sr=
c.
>
> 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.

Pierre, I rarely disagree with you, but this is one such case.

It is true that we can look at this as a partial solution to a bigger
problem, or as you said - a baby step. However, I see this as the
perfect solution for a very narrow, yet also a very common problem,
and I don't see it blocking a more abstract solution in the future.

From a userland POV, it is simple, very effective and there's
practically no way to achieve the same goal with less amount of code.

In short - it's no panacea to all the limitations that we currently
have on property management, but it is still *extremely* useful for
implementing classes that only need to have getters.

On another note, I share Nikita's concern about using the "readonly"
keyword and I'd love that to be improved, but the best alternative I
could think of is "readable" and IMO it doesn't have a clearer
meaning.

Cheers,
Andrey.