I want to pitch in, agreeing with Larry's message here. - There are multiple real life use cases where the combo trait/interface could be replaced by interface default methods - Several modern language apply the technique in one form or another, so it's already proven to be valuable - There are a multitude of userland devs who'd benefit from this feature - The only argument I've heard against this RFC is "it goes against my definition of what an interface should be". I was also thought that same definition, and I also had to unlearn it. Just like I had to unlearn the "only one return per method rule" we were taught in college
Brent > On 12 Jul 2023, at 20:17, Larry Garfield <la...@garfieldtech.com> wrote: > > On Wed, Jul 12, 2023, at 4:00 AM, G. P. B. wrote: >> 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. > > If I could play armchair shrink for a moment, I suspect a lot of people come > from a background where "interface is just the behavior definition, not > implementation" was drilled into them. Which... is the case in older Java > when most of us went through school using older Java. So it's natural to > think that is just a rule of how languages work, and so default methods in > interfaces is just some weird nonsense from people who don't understand > language theory because you didn't learn it in school. > > At least, I know that description applies to me, so I'm assuming it applies > to at least some other folks around here. :-) > > Realizing "oh, wait, I was wrong about the theory of how things work" is > uncomfortable, and hard for a lot of people. I was initially luke-warm on it > for that reason. But seeing how many languages have adopted some form of > default methods and lived to tell the tale is convincing for me that it > actually is a viable "build up a class from separate pieces without having to > manually write 50 proxy methods" solution. There may be smaller issues with > it that need to be ironed out (enforcing methods being defined, it working > better with interface properties, etc.), but the core idea seems to be sound. > > It's taken me a while to get used to going through that "oh wait, I was > wrong" process, so at this point it's not an ego-hit. But that's not a > process everyone has gone through. > > In short, I suspect at least much of the pushback is "that is weird and not > normal, according to the normal I first learned, so it must be a bad idea," > and people just stop there. > > (If you voted no and the above description doesn't apply to you, please do > explain what your alternate reasoning is, because RFC authors desperately > need more feedback than we get right now.) > > --Larry Garfield > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php
