Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115361
Message-ID: <6E3E4594-398B-4219-8B79-7863F54BCD32@stitcher.io>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_F777D33C-3E30-4A89-908E-5746120ECB7D"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
Date: Thu, 8 Jul 2021 05:33:52 +0200
In-Reply-To: <0a035a3f-60ef-4001-8c55-f26ab518c3d5@www.fastmail.com>
Cc: Larry Garfield <larry@garfieldtech.com>
To: PHP Internals <internals@lists.php.net>
References: <E7988419-8D1A-479B-B81C-07E0C109B686@stitcher.io>
 <0a035a3f-60ef-4001-8c55-f26ab518c3d5@www.fastmail.com>
Subject: Re: [PHP-DEV] Readonly properties and interfaces
From: brendt@stitcher.io (Brent Roose)

--Apple-Mail=_F777D33C-3E30-4A89-908E-5746120ECB7D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On 7 Jul 2021, at 23:16, Larry Garfield <larry@garfieldtech.com> =
wrote:
>=20
> 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 =
to=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 =
objects,=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 =
are=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 =
can=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 =
first=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 =
any=20
>> more boilerplate code:
>>=20
>> ```
>> interface HasUuid
>> {
>>    public readonly string $uuid;
>> }
>> ```
>>=20
>> With the addition of readonly properties, now seems like a good time =
to=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 =
<https://www.typescriptlang.org/docs/handbook/type-compatibility.html>>=20=

>> [2]=20
>> =
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-a=
nd-structs/interface-properties =
<https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-=
and-structs/interface-properties> =
<https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-=
and-structs/interface-properties =
<https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-=
and-structs/interface-properties>>=20
>> [3] https://docs.swift.org/swift-book/LanguageGuide/Protocols.html =
<https://docs.swift.org/swift-book/LanguageGuide/Protocols.html>=20
>> <https://docs.swift.org/swift-book/LanguageGuide/Protocols.html =
<https://docs.swift.org/swift-book/LanguageGuide/Protocols.html>>=20
>=20
> The property accessor RFC (which didn't get to a vote) discussed this, =
and specifically proposed making properties part of the interface for... =
basically all the reasons given here.
>=20

I thought the RFC didn't go to vote because Nikita didn't feel like it =
warranted the complexity:

> This RFC overlaps with the Property Accessors RFC. In particular, it =
implements the =E2=80=9Conly implicit get=E2=80=9D aspect, though not =
with the exact same semantics. As mentioned in the RFC, I'm not =
convinced that the full complexity of accessors is truly warranted. =
Supporting readonly properties and asymmetric visibility would cover a =
significant portion of the use-cases, at a lower language complexity =
cost. [1]

Is there any reason to assume property accessors will be reconsidered =
for 8.2?=20

[1] https://wiki.php.net/rfc/readonly_properties_v2#rationale

Kind regards
Brent


> My preference would be to add property accessors in 8.2 (at least the =
asymmetric visibility part), and then redefine `readonly` properties as =
a shorthand for a "get only" implicit accessor property; which, if I =
recall 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.
>=20
> --Larry Garfield
>=20
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php =
<https://www.php.net/unsub.php>

--Apple-Mail=_F777D33C-3E30-4A89-908E-5746120ECB7D--