On Sun, May 28, 2023 at 8:21 AM Jorg Sowa <jorg.s...@gmail.com> wrote:
> Hello, > > I agree with David's statement: > > 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. > > It could be abused creatively. Interfaces define the behaviour of the > object, not the data the object should contain. That's why the properties > are implementation details. Liskov principle describes the behavioral > subtyping, not the state. > Pretty much anything human-made can be abused creatively. And when it comes to coding practices and LSP, one person's anti-pattern is another's best practices, so the subjectivity is strong enough to void the argument. Although a few languages already support properties in interfaces (C#, > Java, Typescipt), so it's not rare case in other languages. However, I'm > not well oriented whether those communities have any problems with them. > Typescript interface property declaration is a wonderful example of data struct. When expecting a Value Object or a Data Transfer Object, instead of being forced to transform your own object into a library's expected object, TS will infer the object compatibility. Since PHP doesn't have the nature of type inference, we could accomplish a similar DX by implementing a library's interface into the VO/DTO. This would reduce a lot of boilerplate. A new PSR-7 version could greatly simplify working with Request objects by making use of public readonly properties on the interface rather than method calls. One could even argue that the current state of PHP actually encourages an "anti-pattern" of providing object data access through behavior rather than accessing properties directly because of the limitation in interfaces not having properties. > My though about this topic. Wouldn't allowing abstract properties in > abstract classes resolve the issue of 'enormous amount of boilerplate code' > without touching interfaces, Zoltán? > > Kind regards, > Jorg > No, because abstract classes aren't a replacement for interfaces. I find the Template Pattern to be a good use case for interfacing through abstract classes and they could benefit from abstract properties, but all of inheritance's shortcomings are still present in abstract classes and not on interfaces. -- Marco Deleu
