Re: [PHP-DEV] RFC [Concept] - Interface Properties
With "Interface Default Methods" potentially becoming a thing, it begs the question for the need to have Interface Properties, at least `private` ones and `private static` ones. How can we have default getters and default setters in an interface if there are no private interface properties to get or set? Ignoring special cases, that is. Of course if the RFC for "Interface Default Methods" fails to pass then this point is moot. -Mike > On May 28, 2023, at 1:51 PM, Erick de Azevedo Lima > wrote: > > As others have said: the interface/contract makes available public stuff > that is what the implementers will make available. So it should not matter > if those are methods or properties. > In the case of a public property, the difference from the method-only > approach is that it's already implicit that the read and write operations > are available (for non-readonly properties, of course). > I like it. It can eliminate a lot of boilerplate and make things more > obvious to the final user of the class that implements the interface. > > -- > Erick > > Em dom., 28 de mai. de 2023 às 14:37, David Gebler > escreveu: > >> On Sun, May 28, 2023 at 5:03 PM Larry Garfield >> wrote: >> >>> On another level, I'd redefine properties and methods slightly. (Public) >>> Properties are not "raw data" but "aspects of the object I can >> manipulate" >>> and methods are "behaviors I can ask the object to perform." >>> >> >> I just wanted to pull out this sentence in particular because I think it's >> very much true of the property hooks RFC where you can attach behaviours to >> what are from the outside accessed as if they were fields - and yes >> properties on interfaces makes at least more sense in that case...but I >> don't think it's true of the RFC Nick is proposing, which would very much >> allow interface designs where a property is simply a (maybe typed) public >> property and does represent a "raw data" value. >> >> I suppose the difficulty for me is that I appreciate "people could abuse >> it" isn't a reason in itself to exclude a feature, where it could prove >> useful in a non-abusive way. But languages have ecosystems and frameworks >> and conventions and idioms around them which go beyond what the language >> strictly does and doesn't permit. People who like Laravel will say you can >> write poor PHP code in any framework and good PHP code in Laravel, and >> they're right, but personally I'd argue Laravel encourages you to write PHP >> code in a way which is commonly and conventionally considered to not be a >> best practice. And I don't like it very much for that reason. It's the same >> for me with properties on interfaces; I think it will encourage people to >> do things that some of the conventional wisdom out there says they probably >> shouldn't. >> >> Anyway, apologies I'm not replying in depth to your comments; I'm just wary >> of descending into a philosophical wayside about principles of programming >> and "best practices". And my views on those things are probably quite >> anodyne, but the margin for difference in good opinions is more than enough >> that I don't want to go there. >> >> -Dave >> >> On Sun, May 28, 2023 at 5:03 PM Larry Garfield >> wrote: >> >>> On Sun, May 28, 2023, at 6:52 AM, 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. >>> >>> Almost never is an abstract class what you want, frankly. An abstract >>> class unnecessarily conflates "is a special case of" and "reuses code >> from" >>> into a single syntax. "Making one thing do two things" is a design flaw >> in >>> most of computer science, and one that PHP has been bitten by multiple >>> times. >>> >>> cf: https://www.garfieldtech.com/blog/beyond-abstract >>> 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
Re: [PHP-DEV] RFC [Concept] - Interface Properties
As others have said: the interface/contract makes available public stuff that is what the implementers will make available. So it should not matter if those are methods or properties. In the case of a public property, the difference from the method-only approach is that it's already implicit that the read and write operations are available (for non-readonly properties, of course). I like it. It can eliminate a lot of boilerplate and make things more obvious to the final user of the class that implements the interface. -- Erick Em dom., 28 de mai. de 2023 às 14:37, David Gebler escreveu: > On Sun, May 28, 2023 at 5:03 PM Larry Garfield > wrote: > > > On another level, I'd redefine properties and methods slightly. (Public) > > Properties are not "raw data" but "aspects of the object I can > manipulate" > > and methods are "behaviors I can ask the object to perform." > > > > I just wanted to pull out this sentence in particular because I think it's > very much true of the property hooks RFC where you can attach behaviours to > what are from the outside accessed as if they were fields - and yes > properties on interfaces makes at least more sense in that case...but I > don't think it's true of the RFC Nick is proposing, which would very much > allow interface designs where a property is simply a (maybe typed) public > property and does represent a "raw data" value. > > I suppose the difficulty for me is that I appreciate "people could abuse > it" isn't a reason in itself to exclude a feature, where it could prove > useful in a non-abusive way. But languages have ecosystems and frameworks > and conventions and idioms around them which go beyond what the language > strictly does and doesn't permit. People who like Laravel will say you can > write poor PHP code in any framework and good PHP code in Laravel, and > they're right, but personally I'd argue Laravel encourages you to write PHP > code in a way which is commonly and conventionally considered to not be a > best practice. And I don't like it very much for that reason. It's the same > for me with properties on interfaces; I think it will encourage people to > do things that some of the conventional wisdom out there says they probably > shouldn't. > > Anyway, apologies I'm not replying in depth to your comments; I'm just wary > of descending into a philosophical wayside about principles of programming > and "best practices". And my views on those things are probably quite > anodyne, but the margin for difference in good opinions is more than enough > that I don't want to go there. > > -Dave > > On Sun, May 28, 2023 at 5:03 PM Larry Garfield > wrote: > > > On Sun, May 28, 2023, at 6:52 AM, 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. > > > > Almost never is an abstract class what you want, frankly. An abstract > > class unnecessarily conflates "is a special case of" and "reuses code > from" > > into a single syntax. "Making one thing do two things" is a design flaw > in > > most of computer science, and one that PHP has been bitten by multiple > > times. > > > > cf: https://www.garfieldtech.com/blog/beyond-abstract > > > > > 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
Re: [PHP-DEV] RFC [Concept] - Interface Properties
On Sun, May 28, 2023 at 5:03 PM Larry Garfield wrote: > On another level, I'd redefine properties and methods slightly. (Public) > Properties are not "raw data" but "aspects of the object I can manipulate" > and methods are "behaviors I can ask the object to perform." > I just wanted to pull out this sentence in particular because I think it's very much true of the property hooks RFC where you can attach behaviours to what are from the outside accessed as if they were fields - and yes properties on interfaces makes at least more sense in that case...but I don't think it's true of the RFC Nick is proposing, which would very much allow interface designs where a property is simply a (maybe typed) public property and does represent a "raw data" value. I suppose the difficulty for me is that I appreciate "people could abuse it" isn't a reason in itself to exclude a feature, where it could prove useful in a non-abusive way. But languages have ecosystems and frameworks and conventions and idioms around them which go beyond what the language strictly does and doesn't permit. People who like Laravel will say you can write poor PHP code in any framework and good PHP code in Laravel, and they're right, but personally I'd argue Laravel encourages you to write PHP code in a way which is commonly and conventionally considered to not be a best practice. And I don't like it very much for that reason. It's the same for me with properties on interfaces; I think it will encourage people to do things that some of the conventional wisdom out there says they probably shouldn't. Anyway, apologies I'm not replying in depth to your comments; I'm just wary of descending into a philosophical wayside about principles of programming and "best practices". And my views on those things are probably quite anodyne, but the margin for difference in good opinions is more than enough that I don't want to go there. -Dave On Sun, May 28, 2023 at 5:03 PM Larry Garfield wrote: > On Sun, May 28, 2023, at 6:52 AM, David Gebler wrote: > > On Sun, May 28, 2023 at 10:33 AM Rowan Tommins > > 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. > > Almost never is an abstract class what you want, frankly. An abstract > class unnecessarily conflates "is a special case of" and "reuses code from" > into a single syntax. "Making one thing do two things" is a design flaw in > most of computer science, and one that PHP has been bitten by multiple > times. > > cf: https://www.garfieldtech.com/blog/beyond-abstract > > > 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. > > > > -Dave > > > There's technically nothing you cannot do with any language once it has > type definitions, functions, and closures. Everything beyond that is > syntactic sugar; including classes themselves. It's a question of which > syntactic sugar gives the sweetest developer experience. > > The core question here is a little philosophical. What exactly is an > interface? Is it "a collection of methods", "a collection of behaviors", > or "how I can interact with this object"? > > If you start from the position that an interface is "a collection of > methods", then yes, interface properties don't fit. However, I'd that's a > too-restrictive understanding of interfaces. "How can I interact with
Re: [PHP-DEV] RFC [Concept] - Interface Properties
On Sun, May 28, 2023, at 6:52 AM, David Gebler wrote: > On Sun, May 28, 2023 at 10:33 AM Rowan Tommins > 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. Almost never is an abstract class what you want, frankly. An abstract class unnecessarily conflates "is a special case of" and "reuses code from" into a single syntax. "Making one thing do two things" is a design flaw in most of computer science, and one that PHP has been bitten by multiple times. cf: https://www.garfieldtech.com/blog/beyond-abstract > 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. > > -Dave There's technically nothing you cannot do with any language once it has type definitions, functions, and closures. Everything beyond that is syntactic sugar; including classes themselves. It's a question of which syntactic sugar gives the sweetest developer experience. The core question here is a little philosophical. What exactly is an interface? Is it "a collection of methods", "a collection of behaviors", or "how I can interact with this object"? If you start from the position that an interface is "a collection of methods", then yes, interface properties don't fit. However, I'd that's a too-restrictive understanding of interfaces. "How can I interact with this object" or "what contracts, in the abstract, does this object fulfill" are more accurate questions answered by an interface. There is a common but naive approach to OOP (which I have expressed myself in the past, so no shade involved here) that "properties are implementation, methods are abstraction." Which... is not unreasonable as a first-order approximation, but is incomplete. If your class has getters/setters (as is common for entities), then there's really no "implementation hiding" going on. There's just extra syntax for a public property. So the existence of those properties is already, de facto, a part of the interface of the object. While you can fake it out with a different implementation inside the get/set methods (as in the various examples in the Property Hooks RFC), in practice it's quite rare to do so. So that clean dividing line is already violated by common practice. So on one level, property hooks and interface properties together let you define the behavior of an object similar to how you do now, but with 1/4 as much code, and without losing the ability to "fake it out" in the few cases it's necessary. It's not violating any separation that isn't already violated in practice. Moreover, methods obviously have their own implementation details. While ideally those are kept fully separated from the outside world, in practice that's impossible. Even if you had an Idris-level type system (with dependent types), you cannot completely specify all behavior in just an interface; If you could, it wouldn't be a type system anymore, just code. :-) So the separation is not perfect on that side, either. On another level, I'd redefine properties and methods slightly. (Public) Properties are not "raw data" but "aspects of the object I can manipulate" and methods are "behaviors I can ask the object to perform." >From that perspective (which seems to be increasingly common, based on the >listed languages that have some version of interface properties and >hooks/accessors), of course properties belong in interfaces. It's
Re: [PHP-DEV] RFC [Concept] - Interface Properties
Hey all On 28.05.23 13:52, David Gebler wrote: On Sun, May 28, 2023 at 10:33 AM Rowan Tommins 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
Re: [PHP-DEV] RFC [Concept] - Interface Properties
On Sun, May 28, 2023 at 8:21 AM Jorg Sowa 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
Re: [PHP-DEV] RFC [Concept] - Interface Properties
On Sun, May 28, 2023 at 10:33 AM Rowan Tommins 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. -Dave
Re: [PHP-DEV] RFC [Concept] - Interface Properties
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. 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. 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
Re: [PHP-DEV] RFC [Concept] - Interface Properties
On 28 May 2023 01:09:39 BST, David Gebler wrote: > >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 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. Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC [Concept] - Interface Properties
On Sun, May 28, 2023 at 9:18 AM Nick Humphries wrote: > > 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. > > Agreed, I think the key question for this RFC to progress is "Should an > OOP > language interface support public properties". > > Imo anything that's publicly visible in a class, should be publicly visible in an interface.
Re: [PHP-DEV] RFC [Concept] - Interface Properties
> Interface properties are already included in the Property Hooks RFC, > which should be going to a vote soon-ish. We hope it passes, of > course. :-) >From what I could see, simple interface properties are not going to be implemented by this RFC (awesome work on the RFC too, it has my full support!). While I would be happy for it to be expanded and included, it would increase the risk of the RFC failing. Having interface properties as a separate RFC might enable a more robust discussion about this the specific issue. For context, C# & Swift (via protocols) support interface properties using a property hook style setup, while Typescript, Kotlin and Dart allow for public properties to be defined without property hooks. Languages that prefer duck typing (Python, Ruby, JavaScript) obviously don't support interfaces at all. Java and PHP being the odd ones out that support interfaces and don't have property support. > Creating the getters leads to enormous amount of boilerplate code. We are experiencing similar frustrations within our team. Most of the time we've resorted to using @property annotations to avoid the boilerplate, however PHPStan has recently started to disallow this on interfaces. > 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. Agreed, I think the key question for this RFC to progress is "Should an OOP language interface support public properties". - Nick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC [Concept] - Interface Properties
On Sat, May 27, 2023 at 9:44 PM Zoltán Fekete 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
Re: [PHP-DEV] 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
Re: [PHP-DEV] RFC [Concept] - Interface Properties
On Sat, May 27, 2023 at 6:24 PM Larry Garfield wrote: > On Sat, May 27, 2023, at 1:39 AM, Nick Humphries wrote: > > Hello internals, > > > > Based on a few discussions I've had recently, my team and I couldn't > > think of any reason why we shouldn't have properties on interfaces as > > 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. > Interface properties are already included in the Property Hooks RFC, which > should be going to a vote soon-ish. We hope it passes, of course. :-) > > https://wiki.php.net/rfc/property-hooks 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. -Dave
Re: [PHP-DEV] RFC [Concept] - Interface Properties
On Sat, May 27, 2023, at 1:39 AM, Nick Humphries wrote: > Hello internals, > > Based on a few discussions I've had recently, my team and I couldn't > think of any reason why we shouldn't have properties on interfaces as > it is common for these to be specified in doc blocks currently. > Timing-wise, this lines up well with dynamic properties being > depreciated. > > I've thrown together a very quick POC, there are many tests and > examples of how this could look. > > https://github.com/php/php-src/compare/master...Humni:php-src:feature/rfc-interface-properties > > Some of the key architectural decisions: > - interfaces can implement the same property (exact type match only) > - interface properties must be public > - interface properties can't be static > - interface properties can be readonly > > Open to feedback from everyone on this - keen to get the ball rolling > quickly on it! Interface properties are already included in the Property Hooks RFC, which should be going to a vote soon-ish. We hope it passes, of course. :-) https://wiki.php.net/rfc/property-hooks --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] RFC [Concept] - Interface Properties
Hello internals, Based on a few discussions I've had recently, my team and I couldn't think of any reason why we shouldn't have properties on interfaces as it is common for these to be specified in doc blocks currently. Timing-wise, this lines up well with dynamic properties being depreciated. I've thrown together a very quick POC, there are many tests and examples of how this could look. https://github.com/php/php-src/compare/master...Humni:php-src:feature/rfc-interface-properties Some of the key architectural decisions: - interfaces can implement the same property (exact type match only) - interface properties must be public - interface properties can't be static - interface properties can be readonly Open to feedback from everyone on this - keen to get the ball rolling quickly on it! Kind Regards, Nick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
