 Let's go. I'm too good? Yeah? Okay. Hello. Hello, everybody. I'm really happy to be here. So thank you for being in this session, in this talk. Let's start, I think. It's time. Let me start the contour. Go. We're going to talk about Drupal 10, which is still a work in progress, right? But it's almost done. From a point of view, from my point of view, so I'm Nicola and, yeah, I'm basically one of the most active contributors on Symphony. So I started, I joined the community, the Symphony community almost, not yet 10 years ago, but almost 10 years ago. And I started sending requests by then and nobody told me to stop, so I just continued. And so I have almost 3,000 requests since the beginning. That's a lot. I like what I do. That's also why I can do that. I'm general manager at Symphony, the company, because there is the open source project, but there is also a company behind that. It's a very small company because we have one main product and it's free. I don't know about you, but it's very difficult to grow business with a free product. So we have conferences. So I invite you to come at Symphony conferences. We have one at Disneyland Paris in November and then an online one in December and then another one in France in Paris. And we're going to have more, of course. After COVID, we are starting again, organizing conferences. So we're figuring out where we're going next. Enough of introduction. Let me present you some core things in Symphony. I think it's always time to remind people how things work in Symphony. You're going to see that it's quite similar to Drupal and it's not by chance. There is a strong relationship between both ways of doing things. So Symphony, what is Symphony? Symphony is an open source software since 2011 for version 2. There used to be a version 1, but it was named Symphony also, but it was just different. So Symphony 2, the one we care about, is a bit more than 10 years old. It's built for the web, built in PHP. That's obvious, but it's good stating the obvious sometimes. It's a collection of the top most used PHP components. So if you look at Packages, the download statistics, you'll see Symphony there at many top ranking components. I say it's the second most used PHP framework after Laravel as a framework only because I didn't con Drupal, which is not a framework exactly, but an application framework. We have about 3,000 unique contributors to Symphony during... So we accumulated this number in 10 years. That's about 500 unique contributors per year. That's the stats we have. That's a lot and we are very happy with that. It's Symphony, all technologies included, back-end technologies included, is one of the most active, if not the most active open source projects in terms of number of contributions. And we are very happy with that because that's a goal, you know, having contributions in any open source software. So that's something that we kind of managed to do correctly and we always try to be better at that. So we created 60 core components. I'm going to mention some of them, not all of them. And we have 200 packages. So components are like, yeah, components, you can imagine what it is. Packages, there are many bridges like Mailer can interface with many providers. Notifier also has many providers. We have polyfills. There's a big list of polyfills. So that accumulates up to 200 packages that we maintain in the project. If we cumulate the total number of downloads, it's vanity number. It doesn't mean anything, but that's still huge. Like four billion cumulated downloads, all versions, all components included and it grows, it accelerates. So I think that's just because people are using continuous integration and these downloads packages all the time, but it's still nice to see that this grows, right? So Symphony is also using this releasing process since the beginning. We release based on the time schedule. So predictability. We decided to go with predictability as a releasing principle. Drupal does the same now and they aligned almost on our schedule. So this is today. Today we have four versions that are maintained, like the 4.4 LTS-1 is about to die in a few months. We have 5.4, which is the current LTS. Like you see, we're going to maintain it for two years. 6.0, 6.1, which is the current stable, and we're about to release 6.2 in two months. And you know that Drupal 10 is going to be based on 6.2, right? So maybe you wonder why Drupal decided to go with 6.2 instead of 5.4. I think that's because they're building for the future, because this future is going to be our past very soon. And so building on the most modern technologies is the way to have less technical depth to start with. And I think that's a very, very good decision. And it's also a very big shift for Drupal. Like if you look at Drupal 9, it's still running on Symphony 4.4, because they decided to go, I guess, with stability first. And now they have kind of years of technical depth to catch up. So it's better, even in your project, to start with the most modern, because modern is going to be obsolete in six months, right? So we have a few processes to help people follow this rhythm, because it's quite hard every six months to have a new release. And it's quite critical to allow the community to follow us and to be always up to date. So those processes, you know, but then the first one is called the backward compatibility promise. And this one is basically semantic versioning applied to PHP. So in, during the, within the same major release cycle, we won't break backward compatibility. We won't rename a class, we won't rename a method, or we won't change the behavior of some piece of code. That's obvious, but that needs to be written somewhere. We won't do that, break backward compatibility. And the other one is a bit more complex. The other one is something that is not covered by semantic versioning. Semantic versioning would allow us to rewrite everything from one major to another major. And actually we decided to go with smooth upgrades. And to do smooth upgrades, we have a continuous upgrade path. I have a slide just after to show you what it means in practice, so that you can have a better understanding of that. The aim here for us, the wish, we wish to have everybody up to date as soon as possible, of course. So for people that do symphony, the things that they need to remember is run composer update every month. Every month that it's not on the table on the roadmap, but every month we do a bug fix release. Right? So every month at the, so we do that at the end of the month. So at the beginning of the month, you can run composer update and get the last bug fixes from symphony. Then every six months, run composer update, but just upgrade patched your composer JSON file to allow the next minor. And do that every six months, and then you have basically three upgrades for symphony dependency. So that's the continuous upgrade path. So we based everything on deprecations. We do not allow a backward compatibility break in the next major without first issuing a warning deprecation in the previous and the current, actually, the current major. That's kind of hard. We have quite often people that come to the repository and say, oh, this is badly designed. I have a better idea. Let's do something else in the next major. We can break everything, right? So I would call that a hard backward compatibility break one without a continuous upgrade path. And we say, no, that's not the way it's going to work. We say, send a request on the current major. Do the work to provide a forward compatibility layer with proper deprecations. And when this is ready, then we'll plan for the change. Sometimes there is no way to move from A to B because B is too far away and we refuse to do those kind of changes. We could, but we don't because of those processes. So that's the first thing. This screenshot is from a test suite report. Like if you run, if you have a test suite, I hope you do. And if you're using the PHP unit bridge, you can see these kind of reports at the end saying, oh, this test triggered those deprecations. So now you can fix them before I'm going to the before, yeah, finishing your upgrade. You don't have to fix them. That's also the deal with deprecations. You don't have to unless you plan to be ready for the next major. So they are not breaking changes on their own. So that's what I mentioned. We figured out this the hard way. Like when we started building the continuous upgrade path, we figured out that we forgot to ask people to raise deprecation when they planned to, when we planned together to deprecate something. And so we did this mistake once when preparing Symphony three. And we spent month rewriting all or adding back all the missing deprecation notices in the code. And so now we won't do the mistake again. So it's a bit harder to contribute to Symphony because of that. We ask people to contribute the forward compatibility layer. But that's fair. That's how everything works smoothly. And there is something that is also maybe not obvious. It's it's not obvious that is to me to convey. It's the last principle of the continuous upgrade path. And it says that you should be able to upgrade the Symphony XOR PHP. So you should be able to. So let's say you have an application, current application. It runs on one version of PHP. You should be able to upgrade the version of PHP without having to upgrade the version of Symphony. And or you should also be able to stay on the same version of PHP and upgrade to the next minor of Symphony. Right. And this is critical to make upgrades smooth. You decide to take the path that is the easiest for you. Symphony will not force you to follow one path which is like which could be like a you must upgrade your PHP infrastructure before moving to the next version of Symphony. Of course, that doesn't work across major versions. But within the same major release cycle, we won't force you to do that. And that's kind of critical. We don't have only code principles. We also have community principles. And I mentioned the 500 unique contributors per year because I think this is something we are doing correctly kind of. We always need to be modest on this topic. But we have a few community principles to make things smooth from a social and human point of view. So we have a core team, of course. So the core team is a set of 20 people that know the processes very well. That's their main skill in the group, in the community. They know all the processes in very deep details, everything I'm mentioning and more. So that's the root of the community. We have a security policy. So this one is technical, but at some point it's not technical because discussing about security issues is something that happens always behind the scene. Because, of course, security should not be public before the release is done. I'm mentioning that also because we receive emails from people that submit bogus or valid security issues. And we have a quite complex process to deal with that. It's complex because it involves also partners. And by partners, I mean the Drupal core team, for example. So when we have an issue in Symphony, we go to Drupal and we say, are you affected? Are you using this piece of code? Yes or no? We do the same with a few other projects and then we have discussion, et cetera. So it's kind of super important for the Symphony ecosystem and the Symphony responsibility on the topic. Another thing that is critical is having welcoming spaces like on GitHub. We learned that that was not always the case. Being welcoming on GitHub, like people come with contributions and then there are reviews, feedbacks. And when we review for something, it's always to criticize, right? So it can be kind of hard because someone comes and put their best there and the first thing they get back is criticism. So it's very difficult to deal with that. I'm sure you have some experience with that or maybe some fear with that. So that's something we try to make as smooth as possible, including telling people how to correctly behave because sometimes that doesn't happen. So when we are extreme cases, we are able to handle that with the code of conduct, which is the set of rules. But from a human point of view, thanks to the care team, which is a group of trained people that knows how to deal with behavioral issues, either online or offline at our conferences also. We have Slack channels. We use Slack a lot in the community. So that's also a place where we need to raise people's awareness about sometimes just kindness. But yeah, that's something that is very important for us, being welcoming and making contributions easy on every aspect. The last aspect to being friendly to people to me is having a friendly continuous integration process. Maybe it's not obvious to integrate that in this slide for you, but I've contributed to many projects, not only Symphony and sometimes, honestly, most of the work is just pleasing a continuous integration for the sake of the fit. It's like, okay, I'm going to do twice the amount of work just to please a tool that is sometimes a bit stupid, but that's the rules it enforces. We try to have a smooth continuous integration to give feedback. And we count on reviews also, human reviews from the court team to catch many things also. Okay, so Symphony is also using cutting edge practices by that, I mean, boring things, but things we have to do because if you open the code base on symphony2.o, you'll see that it's using an old style. What does that mean? So for example, if you open the code for Symphony 4.4, you'll see that it works on PHP 8.1 and even 8.2, which is not yet released, but we have a job there to be ready and we are ready because the code is already stable. So this is modern code and that's part of the process I mentioned before. You know, you remember I said you should be able to upgrade Symphony or PHP. So because Symphony or Symphony 4 is old, but we are still patching it to make it run on the cutting edge version of PHP to allow things to move easily, deprecation less of course. So another thing we did, we are doing, actually we did, in 5.4 it's supporting new language features. Because when I mean supporting 8.4, it means just being able to run that code there. It does not mean supporting the new features of the language. Supporting the new features of the language is a new feature. So back then when we worked in Symphony 5.4, we merged features to have support for attributes, for example, for NMS and many things like that. Not that many actually, those are the main ones. In 6.0 we did that, so drop the deprecated code. That's super fun. It's sometimes hard, but that's fun. Removing code is the most, yeah, it's very enjoyable. And then 6.1 was when it was a work in progress. Because of version 6, we bumped the minimum version of PHP to version 8. And when you have PHP 8, you can start using modern syntax. So that's what we did. We received many pull requests to use modern syntax. I don't remember which ones exactly, but the match construct or things like that. We also improved the type declarations in the code. So either the native type declarations, so written types and argument types. But we also added types for static analyzers, so at salmparam or PHP Stam, so generics basically. So I'm kind of annoyed on this topic because when we prepared PHP 8, we were like, oh, we are going to be able to remove all annotations in the code and replace them with native types. And now annotations are coming back because generics annotations, they are not native construct. OK, I'm kidding, there is a good propose to generic types. So that's something that the community is contributing a lot. So as you can see, this is not about new features of Symphony. This is just about having a modern code base that works well with static analyzers and things like that. So Symphony 6.2, it's still a work in progress. We are adding support for more attributes, but I'm not going to dive into 6.2 now. If you look at the activity on the last year, I counted 8,000 files modified with many lines also, many 100,000 lines. We merged about 2,000 per request in one year, so that's almost six per day every day. So that's quite a lot. And we also split these in three groups, features, so 400, bugs, 700, and minors, 900. So in the change log, you read about the features, you upgrade for the bugs, and you don't care about the minor things. If you look at the activity, minor things are not the majority, but a big chunk of the activity on the repository. So that's what I do, merging costile fixes, annotations, typos, and that's what the community loves doing. Modernizing, this slide is a big amount of activity on the repository. And I think that's great. So this is a slide I borrowed from a Driss keynote a few years ago, and this is still valid, so it's perfect. You know that because of the slide I presented before, we released in May and in November a new made minor version. And you know also that Drupal is now releasing the next month and just after, so that they can release and build on the next version of Symphony every six months. So that's really, really great. We saw Drupal adopting these processes and aligning their release schedule on that, and that makes things so smooth that it just works well. I know how, I know. I can tell, I mean. So let's go, Drupal 10 from Symphony 4.4 to 6.2. So what I did there is I looked at what Drupal is using from Symphony, and I looked at the changelog between version 4 and version 6 for those components. And I'm focusing on the components that Drupal is using in core. There are many more. So this is the first list, so the console component. You don't use it usually, but it's there to provide the commands. Dependency injection is a core one. You are using it every day. It's wiring everything together. Even dispatcher, HTTP foundation, HTTP kernel, of course, you deal with request and restances. MIME, it's just a subset of HTTP foundation, the process component to run processes. You are also using the routing component to map routes to controllers, serializer in a model, like the JSON API model or the REST model. There is a new component, which is the string component that is not in Drupal 9 that you are having in core now. Drupal does not use it, but console is using it. But because it's there, you can build on it. The validator component, the var exporter component is going to be new also in your dependencies. So var exporter is a component that is kind of doing low-level things. So I'm not expecting you to use it directly, except maybe for very specific things, but I'm going to mention that at the end. Var dumper, you know about the dump function. Yarmul, of course, and twig, of course. I'm adding twig there. It's in another project, but it's still the symphony project, the maintaining that. And you are not using those components, and I wish you could. I mean, they are useful. So I'm mentioning them in case you didn't spot they exist. Right? So the cache component, Drupal has its own caching backends and infrastructure. OK, just dropping the ID. Maybe it could be useful. The clock component is a new one, in case you need to muck the time. The .env component is useful when you deploy using 12-factor deployment strategies, things like that. The error handler is part of the dependencies, but just as a transitive dependency, Drupal does not use it for error handling. There are some nice things in there, like throwing runtime deprecations when you are extending a final class or when you are missing an argument. Or basically, it helps upgrade a code. So I don't know if it could be used. HTTP Clients instead of Guzzle. HTML Sanitizer, which could be useful to filter inputs from rich text editors. Mailer to send emails. Messenger, I don't know how you deal with async background tasks, but that could be useful. Notifier to send SMS or chat messages. UID to generate UIDs or Uleads. And the workflow component could be a nice one also to deal with business workflows. So just dropping that, I'm not going to mention that more. And let me dive into some features of those components. So the first feature that is not in a component is the minimum PHP version. So Drupal 10 is going to require PHP 8.1. And the reason why is that we bumped the minimum version of 6.1 to PHP 8.1. If you think about what I told you before, maybe I didn't highlight that enough. But in symphony 6.0, we went with PHP 8.0. And now, if you want to upgrade to the next minor, you have to upgrade your minimum version of PHP. So I broke my promise. Before, I told you you should be able to upgrade symphony or PHP. And now, for symphony application, for 6.1, they have to upgrade PHP before being able to upgrade to symphony, right? So we did that not because it was fun, but because we had to. If you look at the reaction there, there are 140 people that are, yeah, not for the good reason. They are here because they like cutting-edge things. But I like our processes and the stability that comes with that. We did that because it fixes a bug. PHP 8.0 is just broken in a bad way when using preloading. And we had a choice, which was to either consider preloading broken or tell people to upgrade. And we decided to go with the upgrade so that we have less maintenance on our side. Because when there is a bug in PHP 8.0 and you are a symphony user, you go to symphony when there is an issue, right? And so we don't want to deal with the stream of bugs that are going to be reported if we go with PHP 8.0. So that's why we decided to do that. And I think now everybody is super happy to have PHP 8.1 features. So that's great, also. So in PHP 8, I mentioned that before, but just wanting to highlight that it brings native written types, union types also, things like that. It brings attributes. So we are going to adopt attributes more and more, nested attribute for PHP 8.1. It brings enums. And those are the three main features of PHP 8.0 that had a significant impact on symphony itself. And there is a last one that I'm mentioning, which is the serializable interface is dead. So if you read anything that is using it, it is legacy. Do not use that interface. It's broken. That's why it's appropriated. It's too easy to be on it. I say, oh, I want to serialize this. Let's implement serializable. It feels natural, but it's broken. So I want just to send you the message. Don't use that. If you didn't know about that, you know. So let's go. Nice animation, right? So that's a cat. And you'll see why it's there just after. So the symphony string component is an object-oriented abstraction to deal with strings. You know, strings in PHP, there is a list big like that of functions to cut, to split, to pad, to explore, to et cetera, to deal with strings. And in many languages, strings are objects. And we are badly kind of missing that in PHP. And so this component provides you with an object-oriented API. So there is just one line to show you what it can do, like slice a string, obvious. But then you can chain, of course, many steps and put things in uppercase. So it's super nice. The nice thing is that, OK, that's an API to deal with strings. It's just a different way to do something that you can already do, right? There is something more, which is that it knows about Unicode. So when you say split a string, it knows how not to cut in the middle of binary Unicode representation. So it won't cut in the middle of an accent or of an emoji or things like that, right? So if you ask it to give you the first character, it won't give you the first byte. It will give you the first semantic character of what we understand as a character, which is a glyph on the screen, one glyph on the screen, right? And that's not obvious. You can use MVString, Iconv, and you need to use all of them together to correctly deal with that. And that's what the component abstracts. Another thing in string is this, the slugger. So it knows the slugger is a simplification of the topic of transit iteration. So there, you see, we can slug and remove all diacritics accents on a word, on a title, and generate a URL, for example. And we also have the inflator, which is able to singularize or pluralize English words. It's useful in code to generate methods and things like that. So in the process component, that's old. You can already do that. But I like highlighting that when creating a process, don't give it a string, give it an array. This is mandatory now. You could use a string in Symphony 4. Now you have to use an array when you create a process. And the array contains as many items as there are arguments to the command line. If you want to pipe commands like LS, pipe, grep, then you need a shell. The pipe is something that the shell knows how to parse and interpret. And so then you need this kind of what I call prepared command line. You know about prepared SQL statements. So there, there is a placeholder. And the placeholder there is something you give when actually running that. This is safer. This is safe regarding escaping. You might be using escape arg, something like that currently. And you might remember about my SQL escape real escape string, which is something, a complete failure, right? So don't try to escape things. It's always broken. Use prepared command line or prepared SQL query. So in routing, we added an attribute. You can not use it in Drupal yet, maybe. So on the controller, you can control a method. You can give a root attribute and say, OK, this is the path. And this is the requirement for the placeholder. There you see, I have requirement ULIT. This is also a new feature in the routing component. This one you can use it. And it's basically a set of constants that provides regular expressions for common needs. So this is a regular expression for ULIT. And the next one is for a set of digits. And there are, of course, a few more of them for common needs. So you can use that. I wish you could do that in a model. So I'm looking at you. Alex, in case you have an idea how to make this work. So this in symphony would allow loading a directory and looking for annotations there and basically wiring the annotation into the routing system so that you don't have anything to configure any more in this routing file. On the HTTP foundation, it's super stable. So there is one thing I want to mention. And this thing is that there is an RFC which defines headers to tell a server that you prefer avoiding objectionable content. The server defines decide what it means. So basically it means that browser can send clients, can send a request saying prefer safe. So you can check if the header is there using request prefer safe content. And then if you have two different content, one for safe requesting clients and the other one for less safe content, you can say, OK, preference applied safe and very prefer. The body is different. So it varies by the header. Just dropping you the idea in case you have some kind of use case for it. HTTP kernel. In HTTP kernel, we did this rewording to use more inclusive wording in the component. So we deprecated the master word and replaced it by the main word. So that's one of them. There are a few more. This one is still a work in progress. So in stick.2, we decided to, so in HTTP kernel, we do not catch errors. We catch exceptions, but not errors. Like there is a try catch and the catch is not catch throwable. It's catch exception, which means errors pop. And we want to change that. And we did that with an argument to opt in into the new behavior because for what compatibility layer? You want to show that? So this is going to be reverted. I'm proposing to revert that because I'm talking about things that we are talking about right now, both in the symphony repository and in the Drupal repository. So this line is just here to highlight that there is tight communication and interaction between the Drupal core team, which has an issue on this topic, and the symphony core team, which merged something that we are now going to revert because Drupal raised a valid issue. And so that's kind of nice to be able to interact on this topic. We have an annotation on controllers so that you can declare a class as a controller. So you need to have this attribute. This does not work in Drupal because in Drupal attributes are not services. And this requires controllers be a service. That's for another topic. We have a cache attribute where you can define HTTP caching headers, so max age, things like that. So you just add an annotation on a method. And then the request or the response that is going to come back from this is going to be cacheable. And we also have more value resolvers. So this is a controller. You see it uses the root annotation. And it has one argument, which is a UIDv4. And then you see the root text for token. And the token is also required as argument to the method. The token is going to be a string in the URL, but the controller is looking for an object. And the thing that does turn a string into an object is a value resolver. And we have a set of value resolvers in Symphony. So there is one for dates time, one for backed elements, one for UID and a few others. You are already using them value resolvers in Drupal. Those are not working in Drupal yet, but they could very easily. So I'm just suggesting that they should. You'll consider that. And then the big part is the dependency injection component. So in the dependency injection component, we added as support for many attributes. The nicest one is the auto wire attribute. So you can use this attribute now on an argument and have this be injected for you. Instead of relying on explicit configuration, you can do that. I'm going to show you an example after. We also have an argument for tagged iterators. So there you see we have a service, which I call a delegating sneaker. It accepts one argument, which is a collection of sneakers. And this is going to be built by the Symphony DI component out of the list of all the services that implement the sneaker interface. So in one line, you have a collection of services that are going to be injected for you. We have the same for decoration so that you can declare something as decorating something else. I'm going to skip this one. Required is a way to say that a setter needs to be called to properly instantiate an object. So set logger, you add required on it and then you don't have to explicitly say this needs to be called because this means it. All these works in Drupal 10. This does not work on Drupal 10. Auto-configuration is something that does not work in Drupal yet, hopefully. So auto-configuration is some logic to automatically identify objects based on what they implement. And there you see I have an interface, sneaker interface so it relates to the previous slide. And I have an attribute, auto-configured tag. And this attribute says any class that implements this interface should get a tag, a DI tag, which by default will have the same name of the interface so that's why there are nothing in the bracket but I could put a string there. And then that's how we automatically identify and build a collection of sniffers in the previous slide. So there you see we just have a few lines and basically we remove the compiler pass or a provider or basically code we had to write by just explicit declaration. So in Symphony we use expression language and so in order to define some not trivial services so you can use them to build a service as a service factory. So sorry if doesn't mean anything for you, that's a bit cryptic sometimes. And we also are going to have a native support for lazy loading services. So in Symphony we used to require a dependency and a bridge to have services be really lazy. And now we are merging, we added to Symphony the required infrastructure to generate proxies that are needed to lazy load services. I talked with Alex just before the conference, the talk and you already have some infrastructure to have lazy services in Drupal. Maybe you could benefit from the code we have now in Symphony basically outsource that code to Symphony, maybe. So to ensure that all this is actually working I built a small application to just play with Drupal. So this is my model, my model is a barista. So it brews coffee. So this is the set of files I have. So you see at the bottom we have the YAML files to define the services, the routes, everything that is needed. I have a controller to map that to a route, a barista, which is using a coffee machine of course. And then I have a provider because I need to wire things together. So this is my barista thing. It takes a config factory. There you see the config factory. It's going to be auto wired and it's going to inject the config factory service that Drupal provides. So that's all I need to get the config factory. I need also a coffee machine. And then in the body I'm using this coffee machine and I have this comment saying pretend like I'm using the config factory, which I'm not, but just for the example, right. You write that and it works and you can try it on Drupal 10. It's going to work. This is the coffee machine. So the coffee machine takes one argument which is the number of scoops which needs to be brewed. There you see it's a constructor argument and usually to inject a constructor argument into a service you need to add explicit configuration in the YAML file. This does not need to be, this is not mandatory anymore. If you enable auto wiring, then the logic will look at the attribute and will map the parameter in this case and inject that for you. And then you brew things with using whatever logic you want in the method. This is the controller. So the controller is calling Drupal service to get the barista service. It's calling the barista to prepare the drink and it's returning the result for display in the output. There is something that is Drupal style there, the static method called there which is using some global states. I wish there were a way to not use that which would mean making controller services to use dependency injection. So in symphony, we don't do that. We have a constructor and we declare that the constructor accept an argument, a barista object and then we don't have to use any global states. So that's something that could be nice in Drupal. And this is the service YAML configuration that makes everything work together. You see it's empty. And that's the story of symphony in the last years. Figuring out a way to have no YAML configuration and always code, code, code, declare some attributes sometimes when it's needed and then just be in the code editor. And that's a wish you could do in Drupal and you can a bit more actually now. Well, okay, I'm cheating because there is this. I'm cheating. I'm cheating there. If you look at that, it's a Drupal provider and this one is using a finder to figure out all the classes in the service directory and it's loading them, registering them as definition. So basically registering all classes as services. This is something that symphony knows how to do without you writing any code. So I wish Drupal could do that. So my last slide is about, almost my last slide is about this. It would be nice to put services YAML files on a diet which would mean to enable auto discovery so that providers could have less use cases. To enable auto configuration so that symphony could add a tag automatically on services. That would be great. To register control as services to enable custom value resolvers or at least enable the new ones I mentioned before. Right now the list is hard coded so you can change it but you need to do the compiler pass or we write configuration for that. It would be nice to be able to reference some dynamic value. This is using ENV there as a parameter referencing an environment variable. An ID could be to be able to reference a Drupal configuration value. Something that you have already in the database using the config factory service, et cetera. So that you could decouple your parameters from Drupal itself. Could be useful to have the root attribute in case you like it. And that's something I figured I found in the code. There is still a place where service identifiers are forced to be lower case. So I think that's a poor request that could be done these days because there is a check to forbid lower case IDs but this check is in one place and there are many ways around. So basically this doesn't work. And that's another thing. When I built this application I had one tab open with the clear cache button from the admin backend and I had to click on it. So I know that there are better ways to do that. It would be great to have some kind of way to make a short feedback loop when developing a model. When I had a class it would be wired automatically because the cache would be invalidated without me caring about that. So I think there are all the tools on the internet to do that already, to monitor a directory and have this run a command, et cetera. So I'm going to stop on that. Undergo change or be the change. I think that the challenge of Drupal, the challenge of symphony, so always innovate but drop code. Really, it's critical. We survive Drupal and symphony and we are going to survive because we are going to be because we are able to remove code. I think that's the super poor that we have together. So congratulations to the Drupal team for deciding to go with symphony 6.2 to making it actually work. And thank you also for the interactions that we have together. I think both communities work very well together. So I'm really happy with the collaboration we have between both projects. Thank you very much. I'm not sure we have time for Q and A but are you available to stick with me? So yeah, if you've got any questions just come to the front and yeah, we do like that.