On Sat, May 27, 2023 at 6:24 PM Larry Garfield <la...@garfieldtech.com> wrote:
> On Sat, May 27, 2023, at 1:39 AM, Nick Humphries wrote: > > Hello internals, > > > > Based on a few discussions I've had recently, my team and I couldn't > > think of any reason why we shouldn't have properties on interfaces as > > I wouldn't support this, personally. The reason interfaces in most languages which have this concept don't support defining properties is first because they are generally seen as an implementation detail rather than a promise about supported behaviour and second because interfaces are essentially an alternative to multiple inheritance. At the point you're mandating fields as well as method signatures, you're barely one step away from an abstract class anyway. If you still want to combine interfaces with shared properties or default implementations, we already have traits for that purpose. In PHP, two interfaces which define the same method signature can be implemented by the same class, which is at least a little bit iffy in itself. It becomes even more problematic if multiple interfaces can define the same property, because you now don't really know what, conceptually, that property refers to. > Interface properties are already included in the Property Hooks RFC, which > should be going to a vote soon-ish. We hope it passes, of course. :-) > > https://wiki.php.net/rfc/property-hooks For the reasons I've said, I'm not loving the interface part of the property hooks RFC either, to be honest, though I do support the broad feature. I can appreciate that when an interface is used with the hooks, it's more akin to saying an interface is defining setSomething() and getSomething() methods rather than defining a property directly - but it feels like it will encourage writing interfaces which break encapsulation. -Dave
