On Sun, May 28, 2023 at 10:33 AM Rowan Tommins <rowan.coll...@gmail.com> wrote:
> I don't follow. If a property is public, then code outside the class can > rely on being able to access it. That seems to me to be a contract between > the class and its users, not an implementation detail - e.g. removing the > property, or changing its type, would be a compatibility break. A property > can also be inherited from a base class, at which point there is a contract > that all descendants of that base class will have the property available. > So it seems logical that that contract could also be included in an > interface. > > That's why you can declare constants in an interface (a static final property, to use the lexicon of Java) which we can already do in PHP. At the point you want to bring mutable state into an interface, it's a design smell that what you want, really, is an abstract class or perhaps composition. A couple of languages do allow mutable properties on interfaces, TypeScript being one of them, so yes it's not an unheard of feature - but in TS/JS it's a lot more idiomatic to directly access properties than it is in PHP. I'm not too familiar with C# personally but I have a vague recall that the idea of properties on interfaces there is more akin to the property hooks RFC than Nick's proposal here. And although I'm a little uncomfortable with encouraging getters and setters on interfaces, I'm fully behind property hooks, I hope that RFC passes. PHP already has the sufficient design tools to follow SOLID principles and established design patterns well. If this RFC was in the language tomorrow, you wouldn't be able to do anything you can't already do and do more safely, more robustly, with behavioural interfaces and traits. -Dave
