It seems fairly easy to me to implement this proposal in for example symfony DI container. If this would be interesting I can give it a shot to implement a draft for that.
Maybe that will also reveal some issues. But as I see it right now I do not see any blocking issues for that. Op do 2 mei 2024 11:42 schreef Rasmus Schultz <ras...@mindplay.dk>: > To move the discussion along, I decided to do write a preliminary proposal > and create a working prototype: > > https://github.com/mindplay-dk/factory-psr > > In this repository, you will find: > > - Documentation explaining the role and usage of each attribute. > - An implementation of the proposed attributes. > - A use-case example with some mock dependencies and a factory class using > the attributes. > - A sample implementation of a reflection-based FactoryModel reflecting > declared services and extensions. > - A minimal example run-time configured PSR-11 container consuming the > example factory. > - Basic tests to demonstrate a working proof-of-concept. > > I realize your primary concern is with compiled containers and whether > this approach would work - but this is laying the ground work, and it's > much easier to demonstrate than building support for a compiled container, > and we need to start somewhere. > > If someone wants to fork this project and attempt an example with a > compiled container (either a minimal example of a compiled container from > scratch, or an integration with an existing compiled container) please feel > free - I'm not deeply familiar with any compiled container myself. > > For personal reasons, I probably won't be able to do much more in the near > future, but I'm hoping this moves the discussion ahead and maybe inspires > someone else to dig in. :-) > > Cheers, > Rasmus > > On Sunday, April 7, 2024 at 10:59:29 PM UTC+2 Cees-Jan Kiewiet wrote: > >> >> 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. >> >> Awesome 👍. >> >> >> 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. >> >> Compiled as in we don't have to scan everything and figure out what >> should be in the container. Doing that in broadcast where >> https://github.com/WyriHaximus/php-broadcast/blob/master/etc/AbstractListenerProvider.php >> is used as a template and on composer install it scanes for listeners and a >> templated outcome of it is put into >> https://github.com/WyriHaximus/php-broadcast/tree/master/src/Generated >> and will contain >> https://gist.github.com/WyriHaximus/21622fc090f15d18a227f3547f8022c5 for >> that package itself. It's about compiling information into a file and not >> about compiling source code into an executable. >> >> >> 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? >> >> Compiled containers. >> >> > sorry, you lost me. 😅 >> >> It's what I do 😜 >> >> On Fri, 5 Apr 2024 at 06:55, Rasmus Schultz <ras...@mindplay.dk> wrote: >> >>> > 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, <cees...@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...@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+u...@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+u...@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+u...@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 >>> <https://groups.google.com/d/msgid/php-fig/CADqTB_hakquWAz%3D_%2BZbhNM5O%2BURUcWxUZTo-Fz6NoEDhab29-w%40mail.gmail.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 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/648ce3b9-e28a-4b8f-8a95-bb2ae092cce0n%40googlegroups.com > <https://groups.google.com/d/msgid/php-fig/648ce3b9-e28a-4b8f-8a95-bb2ae092cce0n%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/CABS-R8_LaZi5Me4Ly-FuE-WEcu4BjPnZdEFeRrxaX-TRBge8qg%40mail.gmail.com.
