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.
