Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115359
User-Agent: Cyrus-JMAP/3.5.0-alpha0-531-g1160beca77-fm-20210705.001-g1160beca
Mime-Version: 1.0
Message-ID: <0a035a3f-60ef-4001-8c55-f26ab518c3d5@www.fastmail.com>
In-Reply-To: <E7988419-8D1A-479B-B81C-07E0C109B686@stitcher.io>
References: <E7988419-8D1A-479B-B81C-07E0C109B686@stitcher.io>
Date: Wed, 07 Jul 2021 16:16:38 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Readonly properties and interfaces
From: larry@garfieldtech.com ("Larry Garfield")

On Wed, Jul 7, 2021, at 7:32 AM, Brent Roose wrote:
> Hi internals
>=20
> With the readonly properties RFC almost certainly accepted, I'd like t=
o=20
> discuss an idea that's slightly related to them.
>=20
> One of the problems that readonly properties solve is that they reduce=
=20
> the overhead of writing getters and setters. This is especially=20
> noticeable in objects that hold lots of data =E2=80=94 data transfer o=
bjects,=20
> value objects, entities. And while public readonly properties will be =
a=20
> style of programming that not everyone likes, it's clear from the vote=
=20
> on the readonly RFC, as well as the community feedback, that it's a=20=

> feature wanted by many.
>=20
> That brings me to interfaces: currently we're only allowed to define=20=

> methods on interfaces; historically this makes sense, since interfaces=
=20
> are meant to define behaviour, and not the implementation. Most OO=20
> language define behaviour using methods, and state using properties,=20=

> which in turn are used to define the implementation.
>=20
> But now, readonly properties are added.
>=20
> Suddenly, class properties aren't just used for state anymore, they ar=
e=20
> also used to expose that state in an immutable way to the outside,=20
> where we'd use public getters (behaviour) and private properties=20
> (state) in the past, we can now combine them as public readonly=20
> properties. Wouldn't that imply that there are at least some cases=20
> where interface properties could also make sense?
>=20
> A simple example:
>=20
> Imagine we've got 10 different classes that share some behaviour: they=
=20
> are identifiable by a UUID. Next, imagine we've got a function that ca=
n=20
> specifically work with all classes that have a UUID. Proper OO teaches=
=20
> us to write an interface for this behaviour `Identifiable` or `HasUuid=
`=20
> or something alike. This interface would probably require its=20
> implementers to expose a `getUuid(): string` method.=20
>=20
> Without interfaces being able to define properties, we'll now have to=20=

> implement a `getUuid()` method on all our 10 classes, nullifying the=20=

> advantage we got from using `public readonly string $uuid` in the firs=
t=20
> place. If, on the other hand, this functionality was supported, we=20
> could write our interface like so, and wouldn't have to worry about an=
y=20
> more boilerplate code:
>=20
> ```
> interface HasUuid
> {
>     public readonly string $uuid;
> }
> ```
>=20
> With the addition of readonly properties, now seems like a good time t=
o=20
> discuss changing these rules. I realise these questions touch the core=
=20
> ideas of OO, so I reckon some people might have another opinion and I'=
d=20
> like to hear your thoughts.
>=20
> To give you some more reading material, there is a precedent for=20
> interface properties in other languages:
>=20
> - TypeScript supports them [1]
> - C# supports them, albeit using property accessors [2]
> - Swift supports them via Protocols [3]
>=20
> Looking forward to hearing your thoughts.
>=20
> Kind regards
> Brent
>=20
> [1]=20
> https://www.typescriptlang.org/docs/handbook/type-compatibility.html=20=

> <https://www.typescriptlang.org/docs/handbook/type-compatibility.html>=
=20
> [2]=20
> https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/class=
es-and-structs/interface-properties <https://docs.microsoft.com/en-us/do=
tnet/csharp/programming-guide/classes-and-structs/interface-properties>=20=

> [3] https://docs.swift.org/swift-book/LanguageGuide/Protocols.html=20
> <https://docs.swift.org/swift-book/LanguageGuide/Protocols.html>=20

The property accessor RFC (which didn't get to a vote) discussed this, a=
nd specifically proposed making properties part of the interface for... =
basically all the reasons given here.

My preference would be to add property accessors in 8.2 (at least the as=
ymmetric visibility part), and then redefine `readonly` properties as a =
shorthand for a "get only" implicit accessor property; which, if I recal=
l correctly, is essentially the same semantics as `readonly`.  (I didn't=
 check the RFC; I'm going by memory here.)  That would include interface=
 properties by nature.

--Larry Garfield