> But this is also a very abstract PSR, so I personally would love to see easy to grasp and get up to speed examples with say a PSR-18 HTTP Client.
It is just an idea at this stage - yes, an example would definitely be required, likely something a bit more complex than a PSR-18 client, as it needs to demonstrate both factories and extensions, how to do an alias, etc. > Coming from a non-blocking PHP environment with ReactPHP, compiled code is always preferred, even with run times of days/weeks/months. Compiled code? in PHP? please explain. > Since more classic deployment way such as FPM will also benefit from that I'm curious if that should be the default for this PSR. what should be the default? sorry, you lost me. 😅 On Thu, 4 Apr 2024, 22.48 Cees-Jan Kiewiet, <ceesj...@gmail.com> wrote: > On the surface this PSR looks very valuable. If I can provide an easy way > for my packages to be wired up, I'm all in. But this is also a very > abstract PSR, so I personally would love to see easy to grasp and get up to > speed examples with say a PSR-18 HTTP Client. Coming from a non-blocking > PHP environment with ReactPHP, compiled code is always preferred, even with > run times of days/weeks/months. Since more classic deployment way such as > FPM will also benefit from that I'm curious if that should be the default > for this PSR. > > On Tue, 2 Apr 2024 at 23:48, 'Alexander Makarov' via PHP Framework > Interoperability Group <php-fig@googlegroups.com> wrote: > >> Reading https://github.com/container-interop/service-provider/issues/71, >> and it makes perfect sense to me to reboot the WG. Something great might >> come out of it. >> >> On Monday, March 25, 2024 at 12:46:47 AM UTC+3 Ken Guest wrote: >> >>> This all makes sense in at least general terms, and having a PSR to >>> cover this would be great. >>> >>> It would be wonderful to see a working group formed to help advance >>> this, once/if this comes to an entrance vote stage I think I'll be voting >>> in favour of it. >>> >>> Kind regards, >>> >>> Ken >>> >>> On Sun, 24 Mar 2024, 17:09 Rasmus Schultz, <ras...@mindplay.dk> wrote: >>> >>>> But a PSR *can* solve this problem, and the previous PSR did. >>>> >>>> It didn't satisfy the performance constraints of compiled containers, >>>> but it did provide full interop with both compiled and runtime containers. >>>> >>>> So we are talking about: >>>> >>>> - a substantially more complex design >>>> - partially recreating a model of the language within the language >>>> - considerable limitations since every allowed language feature has to >>>> be modeled >>>> - no proper IDE support or static analysis >>>> - lacking interop for extensions in runtime configured containers >>>> >>>> All of this so the compiled containers can avoid calling a factory >>>> function. >>>> >>>> Since this won't fully interop with runtime configured containers, I >>>> would say maybe it's time to reconsider this idea: >>>> >>>> https://github.com/container-interop/service-provider/discussions/69 >>>> >>>> So, an annotated factory class format, designed to enable compiled >>>> containers to inline the factory function body. >>>> >>>> The idea has come up numerous times, most recently here: >>>> >>>> >>>> https://github.com/container-interop/service-provider/issues/71#issuecomment-1900190380 >>>> >>>> It might look something like this: >>>> >>>> https://gist.github.com/mindplay-dk/cd5bf33533a2b7c6fe96469a1b9bd8f6 >>>> >>>> This gets proper IDE support and static analysis for things like >>>> constructor calls - it avoids recreating a model of the language. >>>> >>>> It's more work for compiled containers to inline the factory functions, >>>> sure - but they're doing the work at compile-time anyway. And it becomes >>>> optional - if they don't want to inline factory functions, they don't have >>>> to. >>>> >>>> Since compiled containers need an AST-like model anyway, let them use >>>> an existing, feature-complete language model, e.g. nikic/php-parser, >>>> instead of inventing another one. >>>> >>>> Let users author their providers in the language instead of >>>> manipulating a model - this should be a lot easier for everyone to >>>> understand, even if they don't understand how compiled containers make this >>>> work. >>>> >>>> I think this could be designed to fully interop with both types of >>>> containers, including extensions in runtime configured containers. >>>> >>>> It's just functions with some metadata, which you can parse at runtime >>>> or statically, making as many optimizations as you like. >>>> >>>> On Sunday, March 24, 2024 at 4:31:06 PM UTC+1 Larry Garfield wrote: >>>> >>>>> On Sun, Mar 24, 2024, at 1:47 AM, Rasmus Schultz wrote: >>>>> > There's nothing wrong with anything Larry posted. >>>>> > >>>>> > But I already knew all of that would work. >>>>> > >>>>> > The issue is extensions - if you want to change an argument to a >>>>> > service definition, that requires the original service definition, >>>>> so >>>>> > your extension can change it and return a new one. >>>>> > >>>>> > If you're in Pimple, and you registered the original service using a >>>>> > callback, there is no service definition. >>>>> > >>>>> > How do you get from a function literal to a service definition model >>>>> > instance? You can't. >>>>> > >>>>> > No runtime configured container would be able to provide service >>>>> > definitions as objects, unless the original service definition also >>>>> > came from a standard service provider. >>>>> > >>>>> > Service definitions as data/models are fundamentally incompatible >>>>> with >>>>> > containers that use native functions. >>>>> > >>>>> > I don't think you can fix that. >>>>> > >>>>> > You could have a service providers PSR without extensions, I >>>>> suppose. >>>>> > It's a pretty important feature to just omit though. Every container >>>>> I >>>>> > know of supports extensions. >>>>> >>>>> So... I'm not sure what your point is here? You are correct, if a >>>>> service is registered with a closure, it limits what an extension could do >>>>> to it. But that's not something a PSR *can* solve. That's just how the >>>>> language works. >>>>> >>>>> The answer, whether we're talking compiled or runtime container, is >>>>> for the PSR to define services as AST definitions (the structs like we >>>>> were >>>>> talking about before), and make the extensions manipulate those AST >>>>> definitions. If a particular container *also* wants to support >>>>> closure-based registration, the PSR wouldn't prevent that, but those would >>>>> then be incompatible with extensions and the container just wouldn't pass >>>>> those to extensions. That's it's choice to support additional >>>>> functionality >>>>> beyond what the PSR specifies, and if the language itself limits what that >>>>> functionality can do, um, OK? Not to sound flippant, but that's not our >>>>> problem. Is there something I'm missing here? >>>>> >>>>> Another option, of course, is to break up the interface. Have a >>>>> ServiceProvider interface with one method, an ExtensionProvider interface >>>>> with one method, hell we could even consider a ClosureServiceProvider >>>>> interface if we really really wanted. Let that be opt-in, but with the >>>>> understanding that it won't be used with extensions. Individual >>>>> implementations could opt-in to whichever functionality they wanted, and a >>>>> provider that offers only services or only extensions wouldn't need a >>>>> dummy >>>>> function for the other part. Even without talking about closures, that >>>>> would probably be a good idea. >>>>> >>>>> --Larry Garfield >>>>> >>>> -- >>>> >>> You received this message because you are subscribed to the Google >>>> Groups "PHP Framework Interoperability Group" group. >>>> >>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to php-fig+u...@googlegroups.com. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/php-fig/79061441-ff89-4052-a8d9-0eab9329fdedn%40googlegroups.com >>>> <https://groups.google.com/d/msgid/php-fig/79061441-ff89-4052-a8d9-0eab9329fdedn%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "PHP Framework Interoperability Group" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to php-fig+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/php-fig/2967d7ad-17c2-48d0-9ff4-13b276d16f27n%40googlegroups.com >> <https://groups.google.com/d/msgid/php-fig/2967d7ad-17c2-48d0-9ff4-13b276d16f27n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > > > -- > <http://wyrihaximus.net/> > Website > <http://wyrihaximus.net/?utm_source=signature&utm_medium=email&utm_campaign=emailsignature> > | Blog > <http://blog.wyrihaximus.net/?utm_source=signature&utm_medium=email&utm_campaign=emailsignature> > | > Github <https://github.com/WyriHaximus> | Linkedin > <http://nl.linkedin.com/in/ceesjankiewiet> | Twitter > <http://twitter.com/wyrihaximus> > > -- > You received this message because you are subscribed to a topic in the > Google Groups "PHP Framework Interoperability Group" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/php-fig/SWIfYEkw89I/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > php-fig+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/php-fig/CAPY1sU9BkPLZR4u%2B_98jRt1y0HMi00BxTsUU41zHGiOi2ivybA%40mail.gmail.com > <https://groups.google.com/d/msgid/php-fig/CAPY1sU9BkPLZR4u%2B_98jRt1y0HMi00BxTsUU41zHGiOi2ivybA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CADqTB_hakquWAz%3D_%2BZbhNM5O%2BURUcWxUZTo-Fz6NoEDhab29-w%40mail.gmail.com.
