Re: RFC [Concept] - Interface Properties

> 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