Re: [PHP-DEV] [VOTE] Interface Default Methods
On Mon, 3 Jul 2023 at 01:11, Levi Morrison wrote: > Chatter on the [Interface Default Methods RFC][1] has been quiet for > the past 6 days, and the feature freeze deadline is fast approaching > for PHP 8.3, so I'm moving this to vote. It'll be open for two weeks > as usual. > > Thanks to everyone who discussed weaknesses in the RFC during the > discussion phase. > > [1]: https://wiki.php.net/rfc/interface-default-methods > Although I like the idea, I think the main reason for the pushback is how close this is being voted on before feature freeze when the RFC + implementation was updated very recently before. And personally I think, considering this, I would also delay implementing this. We have at least 2 other major RFCs that are being pushed back (Property Hooks and Function autoloading) due to time constraints. Maybe it's time for a more meta discussion about the absurdly long release process PHP has of releasing many intermediate versions that seem to get no testing from userland. For everyone against this feature, I would urge you to understand the distinction between "type classes" and Java-like "interfaces" (which is effectively what PHP interfaces are). A good article is the following one: https://diogocastro.com/blog/2018/06/17/typeclasses-in-perspective/ I also find it baffling the lack of understanding around this feature. Generic programming exists, and it operates on a level where a method can have a "concrete" default representation and still represent the genericity to its fullest. Examples have already been given, such as the Comparable, Equatable, or Iterator type classes. Considering, Haskell, Rust, Scala, and modern PL theory sees no issue with that, I struggle to understand the resistance here. Moreover, saying this capability should not be added to PHP because we have inferior tools X + Y + Z to achieve what this does is counterproductive and, IMHO, shows a clear lack of understanding of the issues PHP's model currently has. Traits are, and have always been, terribly designed. Assisted copy-paste that has no relation to the type the implementation it provides fulfils. Abstract classes allowing default implementations, but enforcing hierarchy thus type relations, meaning they are unsuitable for when one wants genericity (for separating concerns). Interfaces which allow the creation of new types, but no generic implementation which depend on a function specified by said interface. Objectively, the current situation is suboptimal. Maybe the resistance to the proposal would be far less if the RFC, and implementation, would check at compile time that the default implementations only rely on known existing functions available to the interface. Or that at least one of the methods would remain "abstract". However, that does not seem what the discourse is. I find the Rust Seek trait(/type class) a very concise example of the usefulness, and where the implementation of a default method is far from concrete. Requiring an implementation to provide the implementation for seek(int $position) But being able to provide the trivial implementation of rewind() which is seek(0); Sincerely, George P. Banyard
[PHP-DEV] RFC: Add Reflection*::hasAttribute()
Hi internals, It is common for attributes to be used as markers, and just like a marker interface has no methods, such attributes don’t have any parameter. Examples from Symfony: - #[Ignore] indicating that a property should be skipped in a serialization contextl - #[Exclude] telling the dependency injection container that a given class should be skipped from automatic service registration From Doctrine ORM: - #[Id] to tell which property of en entity class should be mapped as primary key Those attributes are meant to opt in/out some behavior through detection only. But with the current API, such code needs to call `getAttributes()` while it doesn't care about the returned ReflectionAttribute instances. Hence I’m wondering if we could add a `hasAttribute()` method to the reflectors that are targetable by attributes. Does that make sense? If it does, would I need to submit an RFC or would a pull request on php-src be enough? Anyway, I’d be happy to work on the implementation as a first contribution to PHP. Looking forward to your feedback. Thanks. Robin — Robin Chalas
[PHP-DEV] Reflection*::hasAttribute()
Hi internals, It is common attributes to be used as markers. Just like a marker interface with no methods, such attributes don’t have any parameter. Examples from Symfony: - #[Ignore] indicating that a property should be skipped in a serialization contextl - #[Exclude] telling the dependency injection container that a given class should be skipped from automatic service registration From Doctrine ORM: - #[Id] to tell which property of en entity class should be mapped as primary key Those are meant to opt in/out some behavior through detection only. But with the current API, such code needs to call `getAttributes()` while it doesn't care about the returned ReflectionAttribute instances. Hence I’m wondering if we could add a `hasAttribute()` method to the reflectors that are targetable by attributes. Does that make sense? If it does, do I need to open an RFC for that feature or is a pull request be enough? Anyway, I’d be happy to work on the implementation as a first contribution to PHP. Looking forward to your feedback. Thanks. Robin Robin Chalas Principal Engineer @Les-Tilleuls.coop 03 66 72 43 94 ro...@les-tilleuls.coop 82 Rue Winston Churchill - 59160 Lomme
Re: [PHP-DEV] Suggestion: Add optional suffix to tempnam()
On Sat, Apr 12, 2014 at 06:33:40AM +, Ferenc Kovacs wrote: On Sat, Apr 12, 2014 at 12:24 AM, Stefan Neufeind wrote: Hi, I'd like to pick up the original discussion about this patch here again. There have some updates on the github-pull. Maybe somebody could have a look into this, please? https://github.com/php/php-src/pull/575 Kind regards, Stefan Just to make it clear: To make it into 5.6.0 the RFC should have been voted and accepted, and the patch finished and merged before the release of the first beta. None of that happened in time, so now there is no chance to be in 5.6.0. Hi, sorry for reviving this old thread. Is there still interest in pushing the related RFC [1] forward? This thead started few years ago at [2] and has not seen much activity since the proposed change [3] stalled due to issues with test failures. I also found a couple old bugs [4,5] which also requested adding the related feature but they also have not seen any activity since then. I have a first implementation of the feature at [6], but it does have a few points which would need discussion (most likely should go in the RFC). Namely, - the new suffix arg mimics the prefix arg when path separators are present in the string (goes through basename, using only the last part of the provided path); - the suffix gets truncated if its length is longer than 64 characters (also matching the prefix behavior); and - the current proposed patch does not include a windows implementation. I could not find the historical reasons behind the prefix behavior described in the first two points. Then, I was unsure if they should be kept for the suffix. I then took a conservative approach and kept them just to match the prefix arg behavior here. As for not including windows support, the reason lies in the underlying function (and API) used to generate temporary files, which do not provide means to set a suffix and also include a .TMP extension to the files, which AFAICT, does matter in windows systems. I also found a related discussion in an old bug at [7]. I am Ccing the original author here to make sure they get this message so I can understand if they are willing to move forward with the RFC or if I should file a new one (as per the first note in [8]). Finally, as per past discussions on this thread, I understand it is too late to include this change in 8.3, and given the api change, this should be deferred to 8.4 in case an RFC is accepted. [1] https://wiki.php.net/rfc/tempnam-suffix [2] https://marc.info/?l=php-internals=138946779304541 [3] https://github.com/php/php-src/pull/575 [4] https://bugs.php.net/bug.php?id=37613 [5] https://bugs.php.net/bug.php?id=43898 [6] https://github.com/php/php-src/pull/11685 [7] https://bugs.php.net/bug.php?id=44222 [8] https://wiki.php.net/rfc/howto -- Athos Ribeiro -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Interface Default Methods
> So, here's a crazy thought: why do inheritance, interfaces, and traits > need to be separate at all? > > At some level, they're all ways of composing a class with different > restrictions, e.g. inheritance requires a single parent, interfaces must be > abstract, traits don't interact with typing, etc. This RFC was an attempt > to lift some (but not all) of these restrictions on interfaces; in that > sense, it almost seems like too small of a step, and one which leaves the > language in a confusing intermediate state. > I agree with this statement. Although I can't vote, I would be for this feature. However, abstract classes would become orphans with the approval and should be more clarification in the RFC what to do with them and the whole inheritance design in the language, because this is significant change.
Re: [PHP-DEV] [VOTE] Interface Default Methods
On Tue, Jul 11, 2023, 7:32 PM David Gebler wrote: > Looks - sadly to me - like this isn't going to pass. I don't have vote > karma and if I did it wouldn't make a difference to the outcome, but it > would be really good for those of us who can't vote on the feature to hear > from some of the people who voted against it why they chose no. The > feedback from the discussion here seemed overall positive. It's one of > those things that's just a bit opaque to me, that quite often I see people > voting no on an RFC and we haven't heard from them in the relevant > internals threads, so we just never know why something was rejected or what > the author could have said or changed in the RFC to persuade them. > I share some of the sentiment. Although I think we have quite a few people without a vote here on this thread which might had been enough to approve this feature if we all collectively had a vote. Unfortunately the voting system is another broken problem without a fix and it's a really sad outcome at the end. This would had been one of the best PHP improvements since Construction Property Promotion and Short Arrow Functions >
Re: [PHP-DEV] [VOTE] Interface Default Methods
Looks - sadly to me - like this isn't going to pass. I don't have vote karma and if I did it wouldn't make a difference to the outcome, but it would be really good for those of us who can't vote on the feature to hear from some of the people who voted against it why they chose no. The feedback from the discussion here seemed overall positive. It's one of those things that's just a bit opaque to me, that quite often I see people voting no on an RFC and we haven't heard from them in the relevant internals threads, so we just never know why something was rejected or what the author could have said or changed in the RFC to persuade them.
Re: [PHP-DEV] [VOTE] Interface Default Methods
On Jul 11, 2023, at 13:42, Larry Garfield wrote: > > On Tue, Jul 11, 2023, at 5:28 PM, Robert Landers wrote: >> >> IMHO, using a shared base class reflects the inheritance better >> because they are siblings (at least these appear to be logical >> siblings out of context, IMHO) and should look like siblings in a >> class diagram. Their current dis-jointed-ness strikes me as odd and >> the usage of traits in this way strikes me as an anti-pattern. But I >> came from a PHP world where traits were nearly forbidden or used very >> sparingly. > > Traits are a surgical tool with a narrow set of uses, and systems that > over-use them cause problems. (You know which framework you are...) But > this is one of their main valid uses. > > In context, the classes are not siblings, and it would be incorrect for them > to extent from a base class. They just both happen to implement the same > *interface*, but that the same as having the same "is a special case of" > relationship with a base class. > > Having a common base class instead would, as noted before, mean as soon as I > added a third "carries" option, I'd have to add four more base classes to > cover all combinations. It quickly gets absurd, and those base classes have > no valid type usage; they're purely there as an alternative to copy-paste. > > Using inheritance as an alternative to copy-paste is the wrong way(tm) to do > it. Both inheritance and copy-paste. Freshman CS classes still love to talk > about inheritance as a great thing for code reuse but... it's really not, and > many of the 21st century languages have been drifting away from that. > > Traits/default-method-interfaces are a better alternative that doesn't > conflate "copy-paste avoidance" with "is a special case of." Honestly, I > almost never use class inheritance in my greenfield code these days. I'm stating my +1 for this feature (though I can't vote since I lack vote karma), and also want to point that this is a feature in Swift as well, and used extensively through its standard library. (The actual mechanics are somewhat different, and significantly more powerful, both for good and ill. I'm handwaving a bit to not get bogged down in details that don't/can't matter for PHP.) A basic example in Swift's standard library is the Equatable and Comparable interfaces. Both have partial implementations provided. Between the two, if you implement the == and < operations, the stdlib provides !=, <=, >, and >= automatically, but you can override them if desired by providing an explicit implementation. This is used pretty much everywhere; most of the builtin types (like Int, Float, String, and Array, which otherwise have no relation to each other and definitely don't inherit from some base type) implement Equatable and Comparable. Another example is the Sequence interface, which comes with a set of default implementations for standard sequence algorithms, such as map, first, min/max, contains, etc. This allows all types of sequences to have the functionality expected of a sequence without needing to redundantly implement basic operations (unless desired) or participate in inheritance. This clear distinction between what a type _is_ (its type and inheritance tree) and what a type _can do_ (the interfaces it implements) is really important when you start piling on the interfaces. Swift's standard library comes with a laundry list of interfaces that provide partial or complete default implementations, and it's entirely reasonable to combine these together. Consider, for example, a type that implemented each of Sequence, Collection, Encodable, Decodable, Equatable, and Hashable (such as Array or Dictionary). Creating a sane inheritance tree for that would be difficult. (And that's before considering that an array or dictionary should itself be Encodable/Decodable/Equatable/Hashable if its elements (and keys) have those properties. In Swift, the implementation for Array and Dictionary is largely the details of managing data storage. Useful algorithms get automatically inherited from default implementations from their many interfaces without needing a common parent class for both arrays and dictionaries, which are both structs which can't have inheritance anyway.) I'll also point out that (in both PHP and Swift) enums can't participate in inheritance, but can implement interfaces. If one wanted to provide a default implementation for an interface used an enum, an abstract class isn't an option at all. Anecdotally, outside of framework-mandated inheritance, the vast majority of my types in Swift are structs, enums, and classes with no inheritance, and many have interfaces that have some default implementation provided. Most of my PHP classes that have inheritance would be better served with interfaces + default implementations; they use inheritance only because it is currently the least bad way to make them work. Inheritance
Re: [PHP-DEV] [VOTE] Interface Default Methods
On Jul 11, 2023, at 12:03, Peter Kokot wrote: > I really liked this idea actually but I'm still not so sure about it, > what would be the "right" approach. So, here's a crazy thought: why do inheritance, interfaces, and traits need to be separate at all? At some level, they're all ways of composing a class with different restrictions, e.g. inheritance requires a single parent, interfaces must be abstract, traits don't interact with typing, etc. This RFC was an attempt to lift some (but not all) of these restrictions on interfaces; in that sense, it almost seems like too small of a step, and one which leaves the language in a confusing intermediate state. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: [VOTE] Interface Default Methods
On Tue, Jul 11, 2023 at 9:04 PM Peter Kokot wrote: > On Tue, 11 Jul 2023 at 13:37, Levi Morrison > wrote: > > > > On Sun, Jul 2, 2023 at 6:11 PM Levi Morrison > wrote: > > > > > > Chatter on the [Interface Default Methods RFC][1] has been quiet for > > > the past 6 days, and the feature freeze deadline is fast approaching > > > for PHP 8.3, so I'm moving this to vote. It'll be open for two weeks > > > as usual. > > > > > > Thanks to everyone who discussed weaknesses in the RFC during the > > > discussion phase. > > > > > > [1]: https://wiki.php.net/rfc/interface-default-methods > > > > The voting period is about half-way through. For your information, > > it's currently sitting at 10 yes and 13 no votes. Thanks to everyone > > who has voted so far. > > I really liked this idea actually but I'm still not so sure about it, > what would be the "right" approach. Just one question though. With > this, also the protected methods would be possible to define in the > interface? And what about the properties? Properties would be part of > some other RFC? It doesn't say they can't be used, so I assume we'll be able to use traits in interfaces as well.
Re: [PHP-DEV] Re: [VOTE] Interface Default Methods
On Tue, 11 Jul 2023 at 13:37, Levi Morrison wrote: > > On Sun, Jul 2, 2023 at 6:11 PM Levi Morrison wrote: > > > > Chatter on the [Interface Default Methods RFC][1] has been quiet for > > the past 6 days, and the feature freeze deadline is fast approaching > > for PHP 8.3, so I'm moving this to vote. It'll be open for two weeks > > as usual. > > > > Thanks to everyone who discussed weaknesses in the RFC during the > > discussion phase. > > > > [1]: https://wiki.php.net/rfc/interface-default-methods > > The voting period is about half-way through. For your information, > it's currently sitting at 10 yes and 13 no votes. Thanks to everyone > who has voted so far. I really liked this idea actually but I'm still not so sure about it, what would be the "right" approach. Just one question though. With this, also the protected methods would be possible to define in the interface? And what about the properties? Properties would be part of some other RFC? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Interface Default Methods
On Tue, Jul 11, 2023, at 5:28 PM, Robert Landers wrote: >> Real code I wrote a week ago (specifically, for a series of events in a >> domain model): >> >> https://gist.github.com/Crell/f5929e2ee44decd4e9353c41874f26c8 >> >> Two different interfaces, that I want to be able to check against, but their >> implementations are trivial. One of them is used in 2 classes, the other in >> 3. A base class simply wouldn't work, both because it's semantically >> incorrect (these events are not all "special cases of" some common >> definition, that's not the data model), and because then I couldn't have the >> class that uses only one of them. Traits, for now, are the best solution, >> and this is an approach that gets taken a lot. > > Ah, I see. I would have simply created an ErrorResponseCarrier class, > then had PreRouting and PostRouting extend them and implement whatever > other interfaces they needed. > > IMHO, using a shared base class reflects the inheritance better > because they are siblings (at least these appear to be logical > siblings out of context, IMHO) and should look like siblings in a > class diagram. Their current dis-jointed-ness strikes me as odd and > the usage of traits in this way strikes me as an anti-pattern. But I > came from a PHP world where traits were nearly forbidden or used very > sparingly. Traits are a surgical tool with a narrow set of uses, and systems that over-use them cause problems. (You know which framework you are...) But this is one of their main valid uses. In context, the classes are not siblings, and it would be incorrect for them to extent from a base class. They just both happen to implement the same *interface*, but that the same as having the same "is a special case of" relationship with a base class. Having a common base class instead would, as noted before, mean as soon as I added a third "carries" option, I'd have to add four more base classes to cover all combinations. It quickly gets absurd, and those base classes have no valid type usage; they're purely there as an alternative to copy-paste. Using inheritance as an alternative to copy-paste is the wrong way(tm) to do it. Both inheritance and copy-paste. Freshman CS classes still love to talk about inheritance as a great thing for code reuse but... it's really not, and many of the 21st century languages have been drifting away from that. Traits/default-method-interfaces are a better alternative that doesn't conflate "copy-paste avoidance" with "is a special case of." Honestly, I almost never use class inheritance in my greenfield code these days. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Interface Default Methods
> Real code I wrote a week ago (specifically, for a series of events in a > domain model): > > https://gist.github.com/Crell/f5929e2ee44decd4e9353c41874f26c8 > > Two different interfaces, that I want to be able to check against, but their > implementations are trivial. One of them is used in 2 classes, the other in > 3. A base class simply wouldn't work, both because it's semantically > incorrect (these events are not all "special cases of" some common > definition, that's not the data model), and because then I couldn't have the > class that uses only one of them. Traits, for now, are the best solution, > and this is an approach that gets taken a lot. Ah, I see. I would have simply created an ErrorResponseCarrier class, then had PreRouting and PostRouting extend them and implement whatever other interfaces they needed. IMHO, using a shared base class reflects the inheritance better because they are siblings (at least these appear to be logical siblings out of context, IMHO) and should look like siblings in a class diagram. Their current dis-jointed-ness strikes me as odd and the usage of traits in this way strikes me as an anti-pattern. But I came from a PHP world where traits were nearly forbidden or used very sparingly. > As for it being "back door multi-inheritance", well, Java, Kotlin, and Rust > all do essentially that now. So we're hardly breaking new ground, > design-wise. If anything, it's playing catch up on data modeling > capabilities, an area where PHP is still sadly very much lacking. There's a reason I don't use those languages :p but in all seriousness, I get what you're saying. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Interface Default Methods
On Tue, Jul 11, 2023, at 3:16 PM, Robert Landers wrote: > On Tue, Jul 11, 2023 at 4:36 PM Larry Garfield wrote: >> You have to check your vendor folder for an interface, or trait, or abstract >> class. That doesn't change anything. >> >> As noted, now consider a Baz interface. For interface-and-trait, you add 2 >> more definitions. For interface-with-defaults, you add 1. For abstract >> classes, you need to add 4: BazBase, FooBazBase, BarBazBase, and >> FooBarBazBase. > > I guess I don't understand what the interface is solving if you're > creating an interface _and_ a trait, why not just create the trait? It > sounds like you're coupling your interface to a specific > implementation and trying to get multi-inheritance out of PHP. This > seems like a design issue, and this RFC seems like a back-way to > multiple inheritance. Why not just allow multiple inheritance? > >> And that's assuming you're even in control of the base classes; you may not >> even be able to create all those combinations without lots of copy-pasta. >> >> Abstract classes are basically vestigial since PHP 5.4, and have no use >> cases: > > As a user of abstract classes since the early days of C++, I disagree. > > I'd love to see a concrete example, but to me, this just seems like a > bandaid on an architectural smell. Real code I wrote a week ago (specifically, for a series of events in a domain model): https://gist.github.com/Crell/f5929e2ee44decd4e9353c41874f26c8 Two different interfaces, that I want to be able to check against, but their implementations are trivial. One of them is used in 2 classes, the other in 3. A base class simply wouldn't work, both because it's semantically incorrect (these events are not all "special cases of" some common definition, that's not the data model), and because then I couldn't have the class that uses only one of them. Traits, for now, are the best solution, and this is an approach that gets taken a lot. Interface default methods saves a file, and lets us merge the traits into the interfaces. That's basically it. And that's helpful. As for it being "back door multi-inheritance", well, Java, Kotlin, and Rust all do essentially that now. So we're hardly breaking new ground, design-wise. If anything, it's playing catch up on data modeling capabilities, an area where PHP is still sadly very much lacking. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Interface Default Methods
Le 11/07/2023 à 17:16, Robert Landers a écrit : On Tue, Jul 11, 2023 at 4:36 PM Larry Garfield wrote: You have to check your vendor folder for an interface, or trait, or abstract class. That doesn't change anything. As noted, now consider a Baz interface. For interface-and-trait, you add 2 more definitions. For interface-with-defaults, you add 1. For abstract classes, you need to add 4: BazBase, FooBazBase, BarBazBase, and FooBarBazBase. I guess I don't understand what the interface is solving if you're creating an interface _and_ a trait, why not just create the trait? It What's solved here is that you simply don't have to create the trait anymore, in this specific use case, no more, no less. And I do like it. You may not see the point for it, but as a recurrent user of the interface+trait from another package, it does bothers me a lot because it's never clear about the intent when you don't know the trait exists. Having the interface default methods makes it self-documenting and much clearer for the user. There's nothing complex here, it's pure sugar candy, and much appreciated one by many I guess. sounds like you're coupling your interface to a specific implementation and trying to get multi-inheritance out of PHP. This seems like a design issue, and this RFC seems like a back-way to multiple inheritance. Why not just allow multiple inheritance? Regarding the "back-way to multiple inheritance", it's true, and that's how lots of languages that were not design with multiple inheritance in mind solves it, such as Java, and I personally find this rather elegant. -- Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Interface Default Methods
On Tue, Jul 11, 2023 at 4:36 PM Larry Garfield wrote: > You have to check your vendor folder for an interface, or trait, or abstract > class. That doesn't change anything. > > As noted, now consider a Baz interface. For interface-and-trait, you add 2 > more definitions. For interface-with-defaults, you add 1. For abstract > classes, you need to add 4: BazBase, FooBazBase, BarBazBase, and > FooBarBazBase. I guess I don't understand what the interface is solving if you're creating an interface _and_ a trait, why not just create the trait? It sounds like you're coupling your interface to a specific implementation and trying to get multi-inheritance out of PHP. This seems like a design issue, and this RFC seems like a back-way to multiple inheritance. Why not just allow multiple inheritance? > And that's assuming you're even in control of the base classes; you may not > even be able to create all those combinations without lots of copy-pasta. > > Abstract classes are basically vestigial since PHP 5.4, and have no use cases: As a user of abstract classes since the early days of C++, I disagree. I'd love to see a concrete example, but to me, this just seems like a bandaid on an architectural smell. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Interface Default Methods
On Tue, Jul 11, 2023, at 2:04 PM, Robert Landers wrote:
>> Not exactly, How you wanna solve by abstract class two interfaces
>> which can be implemented using let's say two traits - let's say
>>
>> interface Foo {
>> public function foo(): string;
>> }
>> trait HasFoo {
>> public function foo(): string { return 'foo'; }
>> }
>> interface Bar {
>> public function bar(): bool;
>> }
>> traitHasBar {
>> public function bar(): bool { return true; }
>> }
>>
>> Now I can need to implement Foo or Bar separately or together.
>> Using abstract class that would require 3 abstract classes: Foo, Bar, and
>> FooWithBar.
>> With this RFC that would require just two interfaces with default methods.
>
> This seems like a software design issue, not a language issue...
>
> But 3 abstract classes vs. 2 interfaces + 2 traits seems like a better
> tradeoff if you're going to need the coupling anyway. It's more
> obvious that you want/require FooWithBar when you want it. If you're
> expecting these exact implementations, moving them to the interface
> makes it even more confusing.
>
> I want FooWithBar (iow, I want these exact implementations)
>
> I want Foo (iow, I don't care about the implementation)
>
> You can pass a FooWithBar to Foo, but you can't pass a Foo to
> a FooWithBar.
>
> If the default implementation is on the interface ... who knows what
> you have, you'll have to check you /vendor folder.
You have to check your vendor folder for an interface, or trait, or abstract
class. That doesn't change anything.
As noted, now consider a Baz interface. For interface-and-trait, you add 2
more definitions. For interface-with-defaults, you add 1. For abstract
classes, you need to add 4: BazBase, FooBazBase, BarBazBase, and FooBarBazBase.
And that's assuming you're even in control of the base classes; you may not
even be able to create all those combinations without lots of copy-pasta.
Abstract classes are basically vestigial since PHP 5.4, and have no use cases:
https://www.garfieldtech.com/blog/beyond-abstract
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Interface Default Methods
> Not exactly, How you wanna solve by abstract class two interfaces
> which can be implemented using let's say two traits - let's say
>
> interface Foo {
> public function foo(): string;
> }
> trait HasFoo {
> public function foo(): string { return 'foo'; }
> }
> interface Bar {
> public function bar(): bool;
> }
> traitHasBar {
> public function bar(): bool { return true; }
> }
>
> Now I can need to implement Foo or Bar separately or together.
> Using abstract class that would require 3 abstract classes: Foo, Bar, and
> FooWithBar.
> With this RFC that would require just two interfaces with default methods.
This seems like a software design issue, not a language issue...
But 3 abstract classes vs. 2 interfaces + 2 traits seems like a better
tradeoff if you're going to need the coupling anyway. It's more
obvious that you want/require FooWithBar when you want it. If you're
expecting these exact implementations, moving them to the interface
makes it even more confusing.
I want FooWithBar (iow, I want these exact implementations)
I want Foo (iow, I don't care about the implementation)
You can pass a FooWithBar to Foo, but you can't pass a Foo to
a FooWithBar.
If the default implementation is on the interface ... who knows what
you have, you'll have to check you /vendor folder.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Interface Default Methods
On Tue, Jul 11, 2023 at 10:54 AM Michał Marcin Brzuchalski <
michal.brzuchal...@gmail.com> wrote:
> Hi Robert,
>
> wt., 11 lip 2023 o 14:54 Robert Landers
> napisał(a):
>
>> ...
>> Abstract classes solve this problem perfectly. It's part of the type
>> system, it's type-hintable, it's mockable, and it's pretty easy to see
>> what inherits it as people who inherit it already know what the base
>> behavior was when they wrote the code.
>>
>
> Not exactly, How you wanna solve by abstract class two interfaces
> which can be implemented using let's say two traits - let's say
>
> interface Foo {
> public function foo(): string;
> }
> trait HasFoo {
> public function foo(): string { return 'foo'; }
> }
> interface Bar {
> public function bar(): bool;
> }
> traitHasBar {
> public function bar(): bool { return true; }
> }
>
> Now I can need to implement Foo or Bar separately or together.
> Using abstract class that would require 3 abstract classes: Foo, Bar, and
> FooWithBar.
> With this RFC that would require just two interfaces with default methods.
>
> Now you can easily see how bad this goes if you wanna add 3rd interface.
>
> Cheers,
> Michał Marcin Brzuchalski
>
>
I second this. Imagine a class extends LogAwareAbstractClass. It makes no
sense to the type system and it makes it impossible to extend something
that actually is part of the domain definition. Interface Default
Implementation is an elegant solution that doesn't change the state of PHP
while still making things easier and convenient to manage.
--
Marco Deleu
Re: [PHP-DEV] [VOTE] Interface Default Methods
Hi Robert,
wt., 11 lip 2023 o 14:54 Robert Landers
napisał(a):
> ...
> Abstract classes solve this problem perfectly. It's part of the type
> system, it's type-hintable, it's mockable, and it's pretty easy to see
> what inherits it as people who inherit it already know what the base
> behavior was when they wrote the code.
>
Not exactly, How you wanna solve by abstract class two interfaces
which can be implemented using let's say two traits - let's say
interface Foo {
public function foo(): string;
}
trait HasFoo {
public function foo(): string { return 'foo'; }
}
interface Bar {
public function bar(): bool;
}
traitHasBar {
public function bar(): bool { return true; }
}
Now I can need to implement Foo or Bar separately or together.
Using abstract class that would require 3 abstract classes: Foo, Bar, and
FooWithBar.
With this RFC that would require just two interfaces with default methods.
Now you can easily see how bad this goes if you wanna add 3rd interface.
Cheers,
Michał Marcin Brzuchalski
Re: [PHP-DEV] [VOTE] Interface Default Methods
> > a Trait was modified, what gets impacted? Is this not already the case for all tightly coupled code? This RFC proposes to make the least-coupled code in PHP more coupled, so soon, you'll be able to say the same for interfaces (if this passes). I don't understand this RFC. Symfony is a mess in that a class requires an interface, even if there is only one implementation. PHP shouldn't fix that, Symfony should rethink how they're doing inheritance. Abstract classes solve this problem perfectly. It's part of the type system, it's type-hintable, it's mockable, and it's pretty easy to see what inherits it as people who inherit it already know what the base behavior was when they wrote the code. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: [VOTE] Interface Default Methods
On Sun, Jul 2, 2023 at 6:11 PM Levi Morrison wrote: > > Chatter on the [Interface Default Methods RFC][1] has been quiet for > the past 6 days, and the feature freeze deadline is fast approaching > for PHP 8.3, so I'm moving this to vote. It'll be open for two weeks > as usual. > > Thanks to everyone who discussed weaknesses in the RFC during the > discussion phase. > > [1]: https://wiki.php.net/rfc/interface-default-methods The voting period is about half-way through. For your information, it's currently sitting at 10 yes and 13 no votes. Thanks to everyone who has voted so far. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
