On Mon, 3 Jul 2023 at 01:11, Levi Morrison <morrison.l...@gmail.com> 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
