Hey all On 28.05.23 13:52, David Gebler wrote:
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.
For me an Interface defines a contract.When the creator of an interface thinks that adding a public (and possibly readonly) property to that contract then I can not really see where the problem is.
It allows access to the internal state? Yes. As do getters and setters that can already be declared in an interface.
It allows breaking established design patterns? Well... People are very creative in working around what they feel are restrictions.
With providing readonly properties we made it possible to not have to declare getters for properties. But that means that accessing those properties can no longer be part of a contract provided by an interface. So IMO we need a solution to that dilemma for interfaces.
being able to declare public properties via an interface makes only sense to me then.
Just my 0.02€
Cheers
Andreas--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas |
+---------------------------------------------------------------------+
| GPG-Key: https://hei.gl/keyandreasheiglorg |
+---------------------------------------------------------------------+
OpenPGP_signature
Description: OpenPGP digital signature
