8000 [DI] Sometimes, "class FQCN as service IDs" doesn't work · Issue #22851 · symfony/symfony · GitHub
[go: up one dir, main page]
Skip to content

[DI] Sometimes, "class FQCN as service IDs" doesn't work #22851

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
javiereguiluz opened this issue May 22, 2017 · 4 comments
Closed

[DI] Sometimes, "class FQCN as service IDs" doesn't work #22851

javiereguiluz opened this issue May 22, 2017 · 4 comments
Labels
DependencyInjection

Comments

@javiereguiluz
Copy link
Member
Q A
Bug report? yes
Feature request? no
BC Break report? no
Symfony version 3.3

In symfony/demo#562 we're updating the Symfony Demo app to 3.3.0 RC1 and all the new DI features. During the upgrade, @weaverryan suggested to use this config for the Twig Intl extension:

Twig_Extensions_Extension_Intl: ~

When I did that, I saw this error:

RuntimeException in CheckDefinitionValidityPass.php line 52:

The definition for "Twig_Extensions_Extension_Intl" has no class attribute, and
appears to reference a class or interface in the global namespace. Leaving out
the "class" attribute is only allowed for namespaced classes. Please specify the
class attribute explicitly to get rid of this error.

I needed to use this old config to make it work again:

app.twig.intl_extension:
    public: false
    class:  Twig_Extensions_Extension_Intl
    tags:
        - { name: twig.extension }

Ryan seemed very convinced that this should work. So, my question: is this a bug or just an unsupported feature? Thanks!
@nicolas-grekas
Copy link
Member

That's "on purpose": class<>id automapping is only for namespaced classes.

@javiereguiluz
Copy link
Member Author

Is there a technical limitation that forces us to do this ... or was it a decision? Thanks!

@nicolas-grekas
Copy link
Member
nicolas-grekas commented May 22, 2017 •
edited
Loading

see #21453 & #21380

@javiereguiluz javiereguiluz mentioned this issue May 22, 2017
Closed
@javiereguiluz
Copy link
Member Author

Thanks for the info. Let's close this as "won't fix" then. I've opened an issue in the Docs to ensure that this is explained somewhere: symfony/symfony-docs#7935

Thanks!

@javiereguiluz javiereguiluz mentioned this issue May 22, 2017
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
DependencyInjection
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@javiereguiluz @nicolas-grekas
0