Re: Readonly properties and interfaces

> On 7 Jul 2021, at 23:16, Larry Garfield <larry@garfieldtech.com> wrote: > > On Wed, Jul 7, 2021, at 7:32 AM, Brent Roose wrote: >> Hi internals >> >> With the readonly properties RFC almost certainly accepted, I'd like to >> discuss an idea that's slightly related to them. >> >> One of the problems that readonly properties solve is that they reduce >> the overhead of writing getters and setters. This is especially >> noticeable in objects that hold lots of data — data transfer objects, >> value objects, entities. And while public readonly properties will be a >> style of programming that not everyone likes, it's clear from the vote >> on the readonly RFC, as well as the community feedback, that it's a >> feature wanted by many. >> >> That brings me to interfaces: currently we're only allowed to define >> methods on interfaces; historically this makes sense, since interfaces >> are meant to define behaviour, and not the implementation. Most OO >> language define behaviour using methods, and state using properties, >> which in turn are used to define the implementation. >> >> But now, readonly properties are added. >> >> Suddenly, class properties aren't just used for state anymore, they are >> also used to expose that state in an immutable way to the outside, >> where we'd use public getters (behaviour) and private properties >> (state) in the past, we can now combine them as public readonly >> properties. Wouldn't that imply that there are at least some cases >> where interface properties could also make sense? >> >> A simple example: >> >> Imagine we've got 10 different classes that share some behaviour: they >> are identifiable by a UUID. Next, imagine we've got a function that can >> specifically work with all classes that have a UUID. Proper OO teaches >> us to write an interface for this behaviour Identifiable or >> HasUuid >> or something alike. This interface would probably require its >> implementers to expose a getUuid(): string method. >> >> Without interfaces being able to define properties, we'll now have to >> implement a getUuid() method on all our 10 classes, >> nullifying the >> advantage we got from using public readonly string $uuid in >> the first >> place. If, on the other hand, this functionality was supported, we >> could write our interface like so, and wouldn't have to worry about any >> more boilerplate code: >> >> ``` >> interface HasUuid >> { >> public readonly string $uuid; >> } >> ``` >> >> With the addition of readonly properties, now seems like a good time to >> discuss changing these rules. I realise these questions touch the core >> ideas of OO, so I reckon some people might have another opinion and I'd >> like to hear your thoughts. >> >> To give you some more reading material, there is a precedent for >> interface properties in other languages: >> >> - TypeScript supports them [1] >> - C# supports them, albeit using property accessors [2] >> - Swift supports them via Protocols [3] >> >> Looking forward to hearing your thoughts. >> >> Kind regards >> Brent >> >> [1] >> >> https://www.typescriptlang.org/docs/handbook/type-compatibility.html >> >> <https://www.typescriptlang.org/docs/handbook/type-compatibility.htmlS�� >> OE�V ��]Ͽh >> <https://www.typescriptlang.org/docs/handbook/type-compatibility.html>> >> >> [2] >> >> 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> >> <q-p >> �]��Q ge���https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/interface-propertiesM��9vU!�f��L >> J >> <https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/interface-properties>> >> >> [3] >> https://docs.swift.org/swift-book/LanguageGuide/Protocols.html >> <https://docs.swift.org/swift-book/LanguageGuide/Protocols.html> >> >> <https://docs.swift.org/swift-book/LanguageGuide/Protocols.htmlokHD >> V�ɯ�:�Ԉ� >> <https://docs.swift.org/swift-book/LanguageGuide/Protocols.html>> >> > > 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. > 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 “only > implicit get” 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? [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. > > --Larry Garfield > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > <https://www.php.net/unsub.php>