This is bad...

There is no consensus at all. There's no leadership. There's no vision. How do we actually change this right now? Interface default methods and how cool this would be on the PHP ecosystem. Please can we have them? Welcome everyone to PHP urgent or urgent PHP episode 2. Today we are going to cover very important topics including why generics got rejected, type PHP which is a TypeScript of PHP, Nicholas Graas's new RFC and also why Reddit is mad at me and Brent. But let's talk about everything in the betweens. First of all, PHP verse, how was Peach Verse for you? It was awesome. I know it was so great. It was so great. I think what what what was especially good to see is that it did better than last year with like a second edition that's always kind of the hype is kind of gone but it was uh yeah like on all on all aspects it was uh better than last year so I'm looking forward to next year actually Nuno uh we're already planning some things so I already planning next year how what what's the deal with the trailer though the trailer in the PHP documentary do you guys have dates for that one like [snorts] when it will be released Yeah. Yeah. No, nothing yet. No, they're still interviewing people. Uh, so yeah, and we're actually I don't know if I'm allowed to say this, but I'm going to say it. Um, we really want Rasmus in it because that wouldn't make any sense without Raasmus, but Raasmus doesn't really want. So, we're really trying he's just he's busy um as far as I understood. So we're really trying our best there because it would be very weird to have a documentary about PHP without creator of PHP. So Right. Right. Right. Trying our best. Yeah. Mhm. So that was PHP verse and I had a blast by the way. All right. Let's just just dive into the podcast I think. Okay. Let's dive into the podcast. Very very important topics today. Okay. Very important topics including generics got rejected. Do you actually got an understanding like why generics got rejected? Right. They're working on on rayify generics, which means that they want generics to be type checked at runtime. Basically, look, I'm I'm talking to to Rob at the moment who is uh working on this new version of the RFC that's been built on the current RFC. Just for context, the current RFC adds generic syntax without actually checking the types at runtime, which is a good thing. Generics are not a runtime tool. Actually, the whole type system is in a runtime tool, but that's a discussion for another day. Um, and so you just get you get beautiful syntax, you still get to use your static analyzers, and it all just works. Uh, and you get a reflection API, which is really good for framework development and package development that want to use that generic type information during runtime, but not checking the types itself. Uh, so that that RFC is uh not going to happen. too many people vote no because they want uh an an an a new version of the RFC with typed checked uh at runtime basically. So clarify something to me if you don't mind when you say they want rectified generics meaning that they want generics to be checked at runtime. Yeah. Are you saying that everyone wants that like everyone including so because my you know my original thinking when I look at the discussions like everyone is discussion with everyone on that RFC and blah blah blah blah blah my pro my concern is that it will never be a consensus you know because there is multiple there is multiple ways you can approach generics which is what I've talked on the video you can have typer generics which is like the RFC proposed and it's literally like python uh right Now you can have rectified generics which is types being checked at runtime. And that's another way of having generics within a language. I personally honestly I don't care as long as we have generics. But my concern is that they will never actually find a consensus and for that reason we will never see P generics in PHP. I I So do you think do you think if if we have typed checked at runtime generics with uh ratified I think that's the name of that approach. Do you think generic do you think there would there will be a chance of having generics in PHP? I I think the chances have never been as as good as now to be honest. So yes may maybe actually in in one or two years they want to target PHP 9 for it. Um maybe we will actually get generics, but I just I find that that you you ask like who agrees and and what kind of group like the are there are they ever going to find consensus. The whole problem I have with the way that PHP is is governed is that it's a group of very talented programmers but they are all coming with their own agendas and it's just yeah it is it is and and and I find that some very important voices are not represented in that group like the the the big framework uh vendors for example the people who actually drive PHP in real life um and And yeah, it it is a problem. I don't like a committee as what I like to call it. It will always lead to um uh to like an average solution at best because everyone's compromising. Uh you need to find a solution that works well enough for everyone uh for both sides that are on like uh have very different opinions. And does by definition you arrive at average solutions? And I think I would rather arrive at great solutions where 5% of the time I don't agree with whatever is decided, but 95% of time I do. Anyway, that's my opinion and people disagree. Um, and that that's fine, I guess. We'll see. We'll see. It's been 10 years that we've been discussing discussing generics new generics. I know. I know. I know. I know. What did I say? I know. You know, I don't want to make this like a they versus we, you know, but um but uh but I do can I pitch in there because it's super important here that the things I and other people are criticizing isn't people. It isn't individuals. It's just a process that has grown and you can I I acknowledge you cannot just change it from one day to another. Um my honest opinion is that the way PHP is governed these days is far from ideal and PHP would be in a much better place if we changed it and that has that there is no like um judgment over any of the people who are doing very great work on on the PHP RFC's and PHP core. it it but it's just like it's not the ideal situation and I think for PHP to to be a more modern language that that uh can try for the coming two three decades we really need a change that's my opinion you can disagree and I'm totally fine with that um but I I feel like I'm also allowed to to just say that without having to be like said that I'm firing shots or anything but Adrian totally fine yeah but I honestly think Brand like it's kind of Cool. Like I don't know if the fact that I'm now creating content on YouTube and you are also creating content on YouTube like we are literally creating a bunch of content. And we see more people about speaking about PHP internals. Okay. So I'm not saying it's because of us but we do see more and more people talking about PHP internals. Now I think like when something is subject to crit to critics like subject to crit to criticism that's a good thing. Yeah. That's the only way people can actually evolve and the only way things can actually involve. Now, I'm skipping topics here already, but I want to I want to kind of explain my my my thoughts. Okay. Yeah. Go ahead. My thoughts is that currently the PHP internals are like a sealed box, you know, it's very difficult to understand if my opinion is getting hurt, you know. So if any of the PHP internals is listening to me right now, okay, either via podcast or via YouTube live or via YouTube video, just let me know through email or publicly if you want to if you guys hear the community, okay? And I'm part of the community. Brent is part of the community. And if that's the case, perfect. I would, you know, I would really like to know that because my perception right now is that it's not easy for me to get heard and it's not easy for me to understand how I can get heard as well. You know, people say, "Oh, you need to go to the mailing list and have a discussion." That's the most difficult thing in the planet. Like, and I am I think I'm a very smart guy. I'm going to be honest. I think I'm a smart guy and I don't understand how can I go to that discussions. Okay. The last time I have sent an email to the mailing list story, I had to I I had to have a call with someone that someone had to explain me like a few things and that was super confusing. So I think like this is what we have currently. Obviously, there is it's subject to a lot of improv if if I'm honest, but we also have maybe to discuss what is the ideal solution and I've been thinking about this like what is the ideal solution? like if I could snap my fingers and I would just instantly change like there's comedia story there's PHP internals there's debates like how can I instantly do that and I've been thinking about this breast for example discusses everything publicly on GitHub in hindsight that might be like a perfect solution you know it's super transparent but at the same time do we actually want every single one to be able to raise their opinions on things cuz you know maybe I'm like like in in hindsight it may may look a good idea but if everyone can go to a discussion and give their opinions on you might get an opinion from someone who is like very context aware you know someone who has been following this stuff forever and then you get an opinion as well with the same level of visibility of someone who was not involved from the beginning who is not aware of the context so you know in hindsight GitHub looks amazing think GitHub discussions because everyone can participate on them. But at the same time, I do understand that some people's opinion are like a little bit more important than others. You know what I mean? Like if Taylor is if Taylor Otwell spends 3 days investigating to actually write something down to the PHP internals, that opinion needs to have more visibility than some random dude who's just saying double generics and we want generics on the car. So, I don't know, man. Um, what do you think about all of this? I've said uh I I would even go like 10 steps further, Nuno. The way I think successful software um should be uh governed. Um you have the perfect example there. The most what is the most successful project ever in PHP when it comes to like user base but also marketing? No. Okay. No, I Okay. Second second best. I'm Laravel. But actually WordPress is also the same example. Why is that? Because there is one person, one person who has the final say and who is leading the vision of the project. And PHP is no different. PHP is a technical project like anything else. Actually, you can apply this principle on basically everything in the world. You need someone who has a vision, who has people who are willing to follow that vision. That someone that leader person, they should listen to the feedback of the community. they should not just go and and and decide whatever they want. No, they make informed balanced decisions. But there's one person who's driving um he's who's who's driving everything basically as far as I understand with Laravel, even until today. Uh Taylor still gets a final save. He doesn't want a pull request merged in Laravel. It's not going to happen. And that happened a lot in the past. You can say oh oh Taylor is ignoring us or he doesn't understand our use case or this or that. But in the end like see where Laravel is today how successful it is. It cannot be compared like PHP pales in comparison to to the success of Laravel which is like kind of crazy because Laravel is built on PHP but people are now thinking and and and and describing themselves as Laravel developers. They don't even care that it's PHP anymore. Could be any other technology underneath. And this is what Taylor has done so geniusly well and what I think is a much better approach to to software development uh in general. We had some of these people in the past. No, no, we had Resmus in the very beginning. We had at a very later well no not at a very later stage then then um uh Zen came in and kind of took charge and this was a company but still like a single entity with a single opinion uh driving the the language forward. Then there was a huge period where things got very bad. Remember PHP 6, right? Uh then PHP kind of had to get to get their act together because Facebook was going to steal everything from them with hack. Then Nikita came in visionary. Apparently like almost all RFC's that Nikita proposed just like got accepted unanimously. Not because uh they were all the perfect solutions but but because Nikita had a vision for the language and was able to to phrase it and and and stage it in a way that people actually got convinced and were like okay we're going to follow you. And then Nikita left PHP um for reasons and and now we're back at in a stage where there is no consensus at all. There's no leadership. There's no vision. The the only um organization that has gotten trust, financial trust and endorsement from the wider PHP community is a PHP foundation. And even they cannot make any meaningful decision without having to go through a list of 50-ish people who get to decide whether they agree or not. And again that's not a um I'm not making any judgment on those 50 people 50 to 100 people who are doing their very best on on internals and and working on PHP core. They are very talented developers. They are very great people but it's just not the way a software project this scale should be led in my opinion again and I think we have good examples of other ways that work a lot better. And so yeah I yeah um so just to recap a little bit what exactly we have just said in what I have said in my side is that this lack of transparency like of having other people share their their opinions and you know this is what I have kind of expressed and what Brent have expressed from my understanding is that the government decisions is so despared right now across so many people without having this proper leader or visionary and for that reason no decisions are made in the language does not move forward. How do we actually change this right now? Cuz decisions needs to be made by the current season who makes decisions. So we we don't change this. Nuno, it's impossible to change. Um the only thing that can make a change and this happened before. Uh I already mentioned it. It was uh Facebook with hack. uh there should be a competitor to PHP who might actually stir up enough of the of the things happening here that people are like okay maybe we do need a change because otherwise we just lose our whole community something recently has been happening that might actually have a chance there many side notes to make for the record I don't want PHP to go away I love PHP I want it to just be awesome and continue to be awesome I think there is so much more potential here and and there are yeah so from my understanding you want to you wanted the type PHP story to go forward and actually fix PHP [laughter] cuz you know that's what happens with JavaScript like JavaScript they were taking too long to take decisions TypeScript came along and suddenly you have like a perfect language that transpires to JavaScript and it really like it fits like a glove to the JavaScript ecosystem. That's why that's why everyone is doing at the minute TypeScript and I think like can we before we go any further Nuno maybe you need to like give a quick introduction of what type PHP is because 100% 100%. So a small introduction about typ right. Um so for those who are not familiar with typ uh what happened was on the same day the generics RFC got rejected literally on that same day the swoll team renamed their compiler to type PHP. Now if you're not familiar with the SW compiler that's basically something the SW team has been working on that allows the following. So today we have PHP as an interpreted language goes through the various PHP files you have to ship literally the interpreter to the server as well every single time you have a request. So this happens all the time request comes PHP itself will read a PHP files to produce a response. Now what the SW team have done is transform a little bit PHP on something like Go or Rust meaning that the request comes and you have only the binary that filters that request and produces a response. Now why this is interesting for various reasons because you don't have to ship PHP to the server anymore. You just ship a binary that works just magically but also at the same time you have this compilation step that also does some static analysis in the process and you have speed performance improvements like Rust or Go you are shipping a binary to production. Now this was called if I'm not mistaken swole IoT if I'm not mistaken as a project like elephants literally the same the same stuff however the SW compiler brings something a little bit more interesting which is it also works with dynamic code that's probably the biggest thing on this wall compiler is that it also works with dynamic code so if you have an array for example or magic methods like Laravel does it will still continue to work so that is a huge potential for this story Now on the day the RFC got rejected, the SW team renamed their compiler to type PHP. I repeat to type PHP. Now do not tell me that this is not a marketing strategy because it is. Okay. What this story will end up being and I'm praying for that, okay, is a nice visionary behind that project which will bring literally TypeScript kind of to PHP. Meaning that as a PHP lover myself, I will be able to write Type PHP code and that will end up producing PHP itself and working on my PHP projects. This is what type PHP is about and I think like it's potentially what Brandt was saying that could change a lot the future of PHP in the sense that is it will instantly change the governancy behind the code we produce in PHP. So what is your thoughts on type PHP brand? I don't think I have you I don't think you have publicly shared your u your thoughts. I was waiting for this moment Nuno. All right go ahead man. This is my moment. Um, first things first, it's not entirely the same as TypeScript because it actually compiles to a binary and then runs it through their uh runtime or whatever. I I don't know how how it works exactly, but TypeScript just gets compiled to raw JavaScript. This is not getting compiled to just normal PHP anymore as far as I understood. But um, type PHP is super cool. I think it shows what is possible because this is this is done by the swool team who are um swool by the way that's an extension uh for PHP that that's already available that makes a bunch of things asynchronous so these folks are uh uh know what they're doing uh very talented programmers um I think there is a very big big challenge for them you know and you might not expect this but it is the the language and cultural barrier Um these uh the swool folks very talented developers. they are all in China and they have tried to interact with uh PHP internals in the past when fibers was discussed and that that always led to lots of confusion and nothing happening because there is a a huge barrier there um on the language language on the cultural level but also just the fact that that China as a country is kind of isolated from our more western uh point of view right uh on on like they don't get access to YouTube for example they have their own social media channels that when they um they introduced uh the the compiler it's a blog post written in Chinese you have to translate it and then when you want to join their community it's on we chat which most of us don't really have everyone in China have it but uh these are uh pretty big challenges actually for for the project to reach a wide audience across the world I find Um, so that's that's my first thought. Second thought is that I hope that it will end up being something like hack uh where it gains a bit of popularity. Um, and then it kind of shakes PHP internals and and whoever is in charge of PHP shakes them up and and wakes them up and and says like, okay, hm, maybe we need to we we need to make some changes on our side as well because like people are are leaving. Um, so I I hope I hope that's what will happen. And then [clears throat] I'm pretty sure like I I've heard that PHP and SWUL is like huge in China. We did a little bit of of we try to do a little bit of of of research uh on that side as well. But it's pretty difficult again because of like the many barriers. Uh not just for PHP but like on all levels it's it's difficult to reach uh and interact with China. Um, so, um, I I hope it will reach enough popularity to get PHP get our act together. That's basically my stance at the moment. Mhm. So, Right. Right. makes a lot of sense. So, you think that the barrier on the language um will potentially not getting first of all that project that popular because people don't don't even know that it exists. I think that's a very that's a very good point. At the same time, you feel like because one of the problems we saw with hack is that they literally forget the community meaning that the hack was was like originally a very good idea. By the way, hack for those who don't know is this compiler done by Facebook and you know end up actually only work for Facebook and that's partly the reason why it didn't get popular because they literally forget or forgot the community entirely. So hack was not working with Laravel. Hack was not working with Symfony and for that reason hack didn't actually end up being popular and you think that potentially that may also happen with the SW compiler um just because you know we actually don't know right cuz they said the compiler the type PHP compiler will come out in October this year. Yes that's around also when PHP 8.6 come out. Um, so yeah, I don't know man. What I really hope though is I'm able and I think like they really need to nail this. Okay, this they really need to nail this like and we have seen this with Mago as well. Like I really think that for a project to be successful, it needs to instantly work with existing projects. Meaning that a lot of people who are watching this video right now or this podcast or this uh live stream right now, a lot of them they have symfony projects, they have a lot of projects. Okay. Yeah, they see a project like Maggo or Type PHP or others will look very good on paper. They try it down locally and it doesn't work. That's a horrible experience. Okay, I understand that is technical constraints and blah blah blah blah blah blah. But before you actually put anything out, you need to make sure it works properly with Symfony and properly with Laravel because that's what people are doing. Okay, you can say I works very well with native PHP or with raw PHP I mean and vanilla PHP but nobody is doing that like who is doing vanilla PHP? Nobody is doing that. So I think like first of all they need to figure out that story. If type PHP were to be successful since day one in October 2026 they need to figure out that story. Now, if they figured it out that story Mhm. and if they prom if they literally have what they promised on the article because they had some crazy stuff, man, like you can literally chain methods on strings. How crazy this is. You can do hello world dot or arrow and then do two lower and I found that thing fantastic. And if so, if they can bring that thing on the paper to actually something that works for everyone, it will be dope. Uh, yes. then you would also need uh IDE support because that's pretty crucial. You don't want errors all over the place writing the code. So that's also a pretty important uh part which I hope they have on their radar. Um but look at it from a a um western company's point of view. Right here is this company uh company in China leading an open source project where most of the documentation is still in Chinese. they don't uh there are no proper translations of it. um you w would you as a company make the decision to change your stack to a whole other runtime possibly embracing that new syntax so that you're basically locked into like this new language at this point it's not PHP anymore um without the chance to to go back when things go south that is that's a pretty huge risk to take now that's from our western point of view I want to point out like China is is is almost what what one one quarter of the world or something like that they are doing great over there. I don't think they have the biggest incentive to make it worldwide. I don't think that that's needed for their success. Uh so it's more an US problem than their problem. Right. I see. Yeah, that's the IT support needs to be topnotch from the beginning as well, right? So PHPtorm would have to work with it from the beginning, which is a lot of work to think about, right? Because it's a lot of features indeed. I'm having a lot of fun. So, let's move forward to the next topic of today, otherwise we stay here all day. Brent, I love to savage you, but we need to talk about Nicholas Graas new RFC. Can you explain me first of all, who is Nicolas Graas for everyone who don't know him, but also what is this new RFC about? Yeah, Nicholas is is one of the core contributors of Symphony, has been there from the very very beginning almost. I think he's the second man in Symphony. Um and so he he makes a couple RFC's here and there and he just um also proposed an RFC and it went to voting and it's failing uh for a new magic metic called exist which basically tries to solve the problem of um when you use the null coalesing operator or is set on uh a class property for example um it returns true in two cases. It returns true when a property doesn't exist or um has been unset or not never been set before. But it also returns true when the value is null. And so you have one function is set and then null coalesing um that builds on top of that. You have this one concept that actually checks for two things. And so Nicholas, he wants to fix that by adding an optional new magic exists method where you can hook into yourself if you want to um on the class where you can return true or false depending on whether the property actually exists or not. I think it on on lower level code this really is a problem and there are ways around it with reflection which isn't ideal. Um, but especially when you're talking about stuff like data mappers or OMS for example, um, you you need to be able to disting distinguish between a missing property and null. Um, and so you can get around that with reflection, but it's not really ideal. So Nicholas proposes um, a new magic exists method and it's getting Yeah. Do we have the result already of the RFC? It's It's not going to like I think it's 17 people voted no or abstain and no one voted yes. So, wow. Okay. Yeah. My you know my thoughts on the RFC is also no just because I feel like it would first of all would be something just for libraries and maintainers. Okay. It's not something you would do instantly for every single user line project. No. And for that reason that's a no by itself already. Meaning that if we are chipping something to the core just to make slightly easier or just to add a little bit of synatic sugar to something that can be done already and this will be done in used only by framework authors. That's a no. You know I don't feel it's worth the complexity. Nuno, I want to propose a counterargument there because what makes PHP great, it is the ecosystem of frameworks. And so I think it is important to support the frameworks themselves as well because without them there wouldn't be much of PHP left. So um and and like I I think it is it is a real problem. Maybe not on on every project that you might encounter, but don't underestimate how much code you're using and you're building on top of that's underneath there powering everything. Um, so but but the [clears throat] the problem why like no one really likes it that much is because it's another magic method. Another magic method. Yes, I get that. At the same time like it is PHP, right? like what do we plan? We we can't even get consensus on generics, let alone that we'll [laughter] ever be able to to get rid of magic methods. So, I'm I'm here like this is one of these things that I would like to see differently, but at the same time, I'm also like okay, but actually if this solves the issue in a more elegant way than to rely on reflection, um then and and it is consistent with PHP. I mean, there are many magic methods, but now M we don't really want magic methods anymore. I get that. But what are you going to get like get rid of all the other magic methods and no it's not going to happen. So I don't know. Yeah. This goes this goes again into a little bit of the thing where there is no vision. So therefore we don't know exactly where we are going if we are going down the path of strict super strict PHP or or not and um goes a little bit down that path and I think like with 50 people voting it will be literally impossible to actually you know have a vision on this one. I want to speak with you about something real quick before we end this off. I want to speak about how awesome was discussing with Larry Garfield at PHP verse. So Letty Garfield is the creator of many PHP features like enums, pipe operator which is a feature that initially um I did agree but now I don't but he also created that RFC as well. Um he created many RFC's and I find it like when I was discussing with image PP verse I find it like so cool just to be able to speak with someone from the internals. We discussed a lot of things and one of the things we discussed which I kind of want to know your opinion is interface default methods and how cool Yeah. Yeah. So I know what it is by the way. Interface default methods for those who are not aware of it is a feature that actually on Rust already exists. Okay. It means the following. Means that you are able to define what is the contract of a specific implementation but at the same time it can specify as well what is the default implementation like you would do on abstract classes. So he was pitching this to me and I was like that is really good like I I use that on Rust. I would 100% use that on PHP too. Oh man, like I I actually think we talked about this briefly during PHP verse. Even more than generics, I want interface default methods because generics we can we we we have dog block syntax. We'll we'll manage we've been managing for 10 years. We'll be fine. We just want some improvements there. But it's but interface default methods I just did a quick search in in the Tempest codebase. Um there are uh 244 interfaces, right? And for not all of them, but for most of them, we ship a trait with a default implementation because I this is a topic for for probably another day to go like deep dive into it. But I really don't think that uh the classic inheritance approach is um the best way to to go especially when you're talking about technical functionality as with a framework. But anyway, the the interfaces that have just a default implementation that you can still override and then because this is actually where the key is Nuno you I say interface default methods other people say that's just an abstract class right that's very it's not because you can implement multiple interfaces you can have you can have multi-inheritance with interfaces and and as soon as people realize how powerful this is and how much problems are solved. And and the the problem with with multi-inheritance, by the way, is the the classic diamond uh pattern where you have um one class implementing two interfaces where there are um um uh uh what's the word where there are two methods that are named the same or two properties in our case because now we have properties on interfaces as well and that they collide, right? And and how do you deal with those collisions? But the good thing is we with traits we already have a solution for that. We just need to copy it to interfaces and and be done with it. Like the problem in PHP for multi-inheritance has actually already been solved like to solve these collisions. We have it with traits. It's works. It's not super convenient but actually it barely ever happens like these collisions. It barely happens. It's it's not an issue like that that should define whether this RFC succeeds or not. But yeah, so just to clarify, we can already do interface default methods by having three interfaces in a trait for each one of them that specifies the default implementation. So interface default methods would effectively kill abstract classes. I don't see a reason I don't see a reason why I would ever use appar classes ever again if I had the interface default methods at the same time even traits like potentially traits well they would have a use case traits though still for default like for protected methods and private methods you know you can you can you can share effectively but that can be also another class so I think like traits and abstract classes they will be effectively just killed can you have this property on interface method Yes, you can. That's actually a very good question because if you would preserve some state on default implementations on interfaces, how would you for example have a property? That's actually a very very nice question. Like how the RFC solves that? I don't know. I don't know. I know the RFC got rejected already. So, so this was an RFC. Let's see. Uh oh, 2022 already. Time flies. And it got 15 votes in favor and 17 against. Um, so that was close. No, you need the two3 majority. So, yeah, that's what I'm saying. That was kind of close still, you know. Yeah. Yeah. Um, so there's that. Um, yeah. I This would be like absolutely, Nuno, if you ask me what like my number one um feature I want to edit in PHP, it's actually this because it would just it makes my life so much easier. You can't imagine having to name things because I really don't like classes or or interfaces or traits with the same name. Uh so I I I usually opt for the interface to have the clearest name. But then what do you name the trait that goes along like that that interface? I don't really like suffixing with trait either. So yeah, how how how do you deal with that? So in my case what I do like for example there's a the request interface that models a uh an HTTP request right and then the trait with the default implementation that's called is request so because that like this this provides the implementation for the request that's kind of works in 99% of cases and then there are like weird words sometimes that doesn't really work but okay I I like consistency so I'm [laughter] always very anxious to to try to find something that works there. Um, but interface default methods, man. Yeah. Oh, I remember what I wanted to say. You you you mentioned that abstract classes might essentially be gone. I think classic inheritance like the the the the single chain inheritance, the tree, right, where you you start from one point and go down in your class hierarchy. I think it still makes sense to model um more kind of business domains um where you're talking like not from a technical perspective but more from a a a like um uh like say you have an invoice right and you have different types of invoices there I think inheritance can still play a good role uh to to actually use classic extend inheritance to to model different types of invoices, stuff like that, that might work, but when we're talking from a technical point of view, dude, interfaces are so much easier to work with. So, uh so yeah, anyway, yeah, I agree. Interface default methods for the win. Folks, uh thanks for tuning in and I just want to reiterate once more that um I think it's good that we're that we're trying to to voice constructive criticism. Um we should do that more because we can as a community learn from that together. Yes, I can be wrong in areas as well. So, I'm super open to have conversations about like all these topics with people who disagree. Um, and I actually I I do that quite a lot and I'm super grateful that people uh well, some people at least really want to engage in that conversation in a respectful manner and it's important like literally we are I'm creating content now about PHP internals and I love how this is shaking things you know you are creating content too. We are both like shaking things like this is just a reality. Like you go to Reddit, people are just like going nuts. We go to Twitter, people are going nuts as well. This is so good to spike criticism and therefore things are going to evolve. This is it for PHP and urgent PHP. Make sure you click on the like button, subscribe the channel. Love you all and catch you guys next time. Peace out. Bye-bye.