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
<https://groups.google.com/d/msgid/php-fig/CABS-R8_LaZi5Me4Ly-FuE-WEcu4BjPnZdEFeRrxaX-TRBge8qg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
