> 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.
I’m no contributor so far but I’ll get there. I must say I’m very excited about this, and I hope, me elaborating on how It would make my life much better, would change your mind. I’m software architect of a team, and we are working on a product configuration. It has an SDK too and the service right now maintains 2 versions - to be precise v2 and v3. Now, to not couple the created service classes to the data transfer objects of a certain version, and to make them reusable through multiple versions, in every endpoint the first thing we do is, that we map them into classes that are not tied to a version. Creating the getters leads to enormous amount of boilerplate code. The properties are public and readonly no point for getters even. Abstract class could help this but it’s like using a tube wrench for a nut. Also one class can extend only one abstract class. By simply defining interfaces with properties would save a lot of boilerplate code and there would be no need for all the transferring from class A to class B with exactly the same properties. > 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. Why would it be a break of encapsulation? Having the `getSomething` and `setSomething` methods or the hooks are essentially the same as if just we have have the public property there. Just less code will be written. Zoltán
