8000 [RFC][DI] Deprecate ConfigurationExtensionInterface / ExtensionInterface / ConfigurableExtension · Issue #42754 · symfony/symfony · GitHub
[go: up one dir, main page]
Skip to content

[RFC][DI] Deprecate ConfigurationExtensionInterface / ExtensionInterface / ConfigurableExtension #42754

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
ro0NL opened this issue Aug 26, 2021 · 2 comments
Closed

[RFC][DI] Deprecate ConfigurationExtensionInterface / ExtensionInterface / ConfigurableExtension #42754

ro0NL opened this issue Aug 26, 2021 · 2 comments
Labels
DependencyInjection RFC RFC = Request For Comments (proposals about features that you want to be discussed)

Comments

@ro0NL
Copy link
Contributor
ro0NL commented Aug 26, 2021

Hi,

This is a proposal for deprecation, in effort to simplify our bundle/extension ecosystem. It's related to #42647

AFAIK any extension is "config-aware", proven by

symfony/src/Symfony/Component/DependencyInjection/Extension/ExtensionInterface.php

Line 28 in 676bd76

public function load(array $configs, ContainerBuilder $container);

And any extension may have a configuration-schema, enabled by: ConfigurationExtensionInterface

To me this is unnessecary layering. The nullability of ConfigurationExtensionInterface::getConfiguration() creates an extra case also.

I propose to deprecate ConfigurationExtensionInterface, in favor of

ExtensionInterface::getConfiguration(ContainerBuilder $container): ?ConfigurationInterface

This conveys the extension config is either schema-based, or mixed.

I dont think config-awareness is needed to initialize a schema. Hence i left out the $config(s) parameter on purpose. Please remind me of a usecase, if it exists :)

If we then reason futher, why not move everything to Extension instead? Thus deprecating ExtensionInterface also.

Or put different, why:

symfony/src/Symfony/Component/DependencyInjection/Extension/Extension.php

Line 27 in 676bd76

abstract class Extension implements ExtensionInterface, ConfigurationExtensionInterface

If we then reason further ^^ ..., why do we have ConfigurableExtension actually? Shouldn't the merged config be our final concern? This is probably the hardest to get rid of, in some sane way. But i'd like to solve the $configs vs $config conflict basically.

WDYT?
@carsonbot carsonbot added DependencyInjection RFC RFC = Request For Comments (proposals about features that you want to be discussed) labels Aug 26, 2021
@ro0NL ro0NL closed this as completed Sep 10, 2021
@ro0NL ro0NL mentioned this issue Oct 25, 2021
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
DependencyInjection RFC RFC = Request For Comments (proposals about features that you want to be discussed)
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@ro0NL @carsonbot
0