Dear Members of the PHP-FIG,
As you may have seen, I have been trying to revive the ServiceProviderInterface proposal. Since the original proposal was largely rejected by major frameworks such as Symfony and Laravel, I have been trying to understand their reservations, and experimenting with alternatives and improvements. I'd like to present a potential refactoring of the ServiceProviderInterface, an idea that could address some critical concerns about the performance of standard containers in the context of compiled containers. This idea aims not only to refine the existing concept but also to enhance its appeal and applicability across the wider PHP ecosystem, particularly for larger frameworks. To my understanding, reservations about the current proposal primarily revolved around the use of callbacks, which posed challenges for optimizations like compiling to static PHP factories or serialization - as well as the necessity for upfront instantiation and registration of providers. To recap, the current proposal looks essentially like this: [image: Screenshot 2024-01-31 113702.png] The the idea for a refactored ServiceProviderInterface would look like this: [image: Screenshot 2024-01-31 113715.png] This refactored interface introduces key changes to address the mentioned concerns: 1. *Replacing Callbacks with Direct Methods:* The use of explicit methods ( createService and extendService) replaces callable factories and extensions. This approach aligns better with static analysis and compile-time optimizations, potentially enhancing performance. 2. *Utilizing Native PHP Types for Type-Hinting:* The refactored interface leverages native PHP types, improving type safety and reducing the reliance on doc-blocks. 3. *Compile-Time Efficiency:* Methods like getServiceKeys and getExtensionKeys enable determining services and extensions at compile time, avoiding the need to call and merge keys/value maps in compiled factories at run-time, reducing runtime overhead and memory usage, beneficial for apps with large number of providers. 4. *Flexibility in Service Creation:* Allowing for optimizations such as the switch statement within createService and extendService methods, which is especially beneficial for apps/frameworks managing a large number of services. Before advancing this idea further, I am asking for your preliminary feedback - particularly from the maintainers of major frameworks and compiled containers who rejected the current proposal in the past. Your input is crucial in determining whether this refactored interface could potentially align with your architectural philosophies, optimization strategies, and performance constraints. - Would this approach potentially address your performance concerns? - Are there any specific aspects of this refactoring that would make integration into your frameworks more feasible? - Would you be open to considering adoption if this idea progresses? If there is positive indication, the next step would be prototyping - adding support for this interface in some container forks, porting some of the existing standard providers, and gathering practical insights. To be clear, I'm not expecting you to do any of that work. I'm only looking for an indication as to whether this idea could potentially address some of your needs - whether it is worth pursuing. I understand that the adoption of any provider standard is a significant commitment, and I am not asking for any sort of commitment - just an indication of whether this refactoring might be seen as a better direction. I believe this proposal still has the potential to add real value for the broad PHP community, and I'm willing to put in some work to try to align it better with the technical and performance aspirations of its major players. Your input would mean a lot to me. Thanks, Rasmus Schultz -- 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/395d1305-3c33-419d-9111-e11f8f3fe230n%40googlegroups.com.
