This proposal looks good, and I would like to make a small clarification. Arguments "$id" do not agree with the methods "getServiceKeys()" and "getExtensionKeys()". Maybe rename methods to "getServiceIds()" and "getExtensionIds()"?
On Wednesday, January 31, 2024 at 1:58:14 PM UTC+3 Rasmus Schultz wrote: > 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/e535117f-a36f-4b7c-b396-d984c875cbbfn%40googlegroups.com.
