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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/01e63eae-fef3-490a-961a-c95be1ff0fa0%40app.fastmail.com.
