On Sun, Mar 24, 2024 at 10:31 AM Larry Garfield <la...@garfieldtech.com> 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+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 > . > This proposal to build a PSR around this does seem reasonable and widely usable to me, so it would get a favorable entrance vote from me. Like Larry said, if a working group can be convened, the continued technical aspects of the discussion can continue there. CRB -- 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/CANsgjnuqLGEE5WVfPYHfDoKQR9nBS7iKQmw%2BZyiG21PNtNEJuw%40mail.gmail.com.
