On Sat, May 27, 2023 at 9:44 PM Zoltán Fekete <fekzol.13...@gmail.com> wrote:
> 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. > Interfaces (as they are) and traits describe one of the possible solutions you can use there. > 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. > I would say getters and setters don't [as a rule-of-thumb] really belong on interfaces, since they by definition relate to properties of an object and properties are by definition an implementation detail. I don't want to get into a debate about principles of OOP and design practices, this list isn't the place for it. I don't want to sidetrack the discussion. I suppose what an interface should conceptually be in PHP is necessarily relevant to whether or not one supports this proposal, though. So yes anyay, my view is that between interfaces as we have them today, traits and abstract classes, there isn't a problem which needs to be solved by now allowing properties on interfaces, but it would open up a likelihood of encouraging things which are often regarded as anti-patterns. -Dave
