Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78304
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.208 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
In-Reply-To: <CAF+90c9UVyX=QVaTHiMe5LEuSYs4ODqu=X1zBKsZCtYOQCMsQw@mail.gmail.com>
Date: Fri, 24 Oct 2014 12:59:18 +0100
Cc: PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <51598611-8662-4E23-9D83-008C42487BD0@ajf.me>
References: <6E04B9BE-854E-4112-8C74-7D90BD8BFE95@ajf.me> <CAF+90c9UVyX=QVaTHiMe5LEuSYs4ODqu=X1zBKsZCtYOQCMsQw@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Readonly Properties
From: ajf@ajf.me (Andrea Faulds)


> On 24 Oct 2014, at 11:20, Nikita Popov <nikita.ppv@gmail.com> wrote:
>=20
> While I think the functionality behind this proposal is nice in =
principle, I have two objections with the RFC:
>=20
> 1. It uses the "readonly" modifier, to refer to a property that is =
publicly readable, but protectedly writable (or protectedly readable and =
privately writable). This isn't entirely obvious from the term =
"readonly" and also does not match the behavior of other languages =
employing a "readonly" modifier, like C#. An additional complication may =
be encountered in the case where the readonly property stores an object, =
in which case I presume it will be possible to modify the stored object =
($obj->readonlyProp->prop =3D 42), which is likely not expected =
"readonly" behavior.

It=E2=80=99s not the best name, I agree, but there isn=E2=80=99t a =
better name I could come up with in discussions. I don=E2=80=99t think =
the object thing is an issue, it=E2=80=99s not like there=E2=80=99s much =
we can do about that.
>=20
> 2. If the aim of this RFC is to replace the getFoo() pattern with the =
use of "readonly public $foo" properties, a primary difference will be =
that a getFoo() method can be declared in an interface, whereas a =
"readonly public $foo" property cannot be. Thus code making use of =
interfaces will not be able to employ this feature. And I don't think =
that allowing properties in interfaces is reasonable at this point, =
because the implementations will be limited to simple-storage properties =
- only with more comprehensive property accessor support would =
implementations be allowed to use more complex backing code.

Right, interfaces currently can=E2=80=99t declare properties and I=E2=80=99=
m not going to change that in this RFC. If I revisit getters and =
setters, that would be changed. Still, I think there is usefulness to =
this without interfaces=E2=80=A6 it=E2=80=99s just more limited, sadly.

It would work quite well with getters and setters and interfaces, if =
later added. Within interfaces, readonly could be used to avoid =
compelling implementing classes to support writing:

interface Point {
     public readonly $x, $y;
}

But without preventing implementing classes from supporting it.
--
Andrea Faulds
http://ajf.me/