Skip to content

[DI] Tag subscribers for collecting tagged services? #22649

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
chalasr opened this issue May 5, 2017 · 8 comments
Closed

[DI] Tag subscribers for collecting tagged services? #22649

chalasr opened this issue May 5, 2017 · 8 comments
Labels
DependencyInjection Feature

Comments

@chalasr
Copy link
Member

chalasr commented May 5, 2017

Q A
Bug report? no
Feature request? yes
BC Break report? no
RFC? yes
Symfony version 3.4

Service subscribers can be used by services knowing exactly what services they need (requires a static list of identifiers), creating service locators from a compiler pass remain the only way to collect and map services corresponding to a given tag, injecting the locator by hand into the requesting service.

Would it be interesting to give the ability to service subscribers to request all registered services for a tag (tagged services subscribers)? This could be done by introducing a variant of ServiceSubscriberInterface like:

interface TagSubscriberInterface
{
    public function getSubscribedTag()
    {
        return [
            'console.command', // request access to services tagged "console.command"
            'console.command' => Command::class // skips non Command subclasses
        ];
    }
}

It would remove the need for creating compiler passes that are dedicated to collect services without performing any special treatment on those.
@chalasr chalasr mentioned this issue May 5, 2017
Closed
@ro0NL
Copy link
Contributor

ro0NL commented May 5, 2017 •
edited
Loading

Does it conflict with #22200?

It would remove the need for creating compiler passes that are dedicated to collect services without performing any special treatment on those.

We're more or less solving the same issue.. right? Not sure.. but tend to favor a config-only approach. But maybe we can have both?

@nicolas-grekas
Copy link
Member

nicolas-grekas commented May 5, 2017 •
edited
Loading

I also prefer config based approach. ServiceSubscriberInterface is generic and has nothing specific to Symfony: it just gives more info about the way some code works. This TagSubscriberInterface would require something really specific for Symfony internals.
We'd better make writing some compiler passes easier - or not required thanks to generic config, as #22200 tries to do, IMHO.

@chalasr
Copy link
Member Author

chalasr commented May 5, 2017 •
edited
Loading

I missed #22200, I agree.
Btw, it makes me think that we should not have fully replaced !service_locator { foo: @foo1} (that I would rename as !map: { foo: '@foo1' } today), it is nice for people which do not want DIC-specific stuff in their code IMHO.
Closing then, thanks for your thoughts.

@chalasr chalasr closed this as completed May 5, 2017
@ro0NL
Copy link
Contributor

ro0NL commented May 7, 2017

@chalasr 👍 for !map { }

That way #22200 can leverage !map + !iterator, and introduce !tagged_map + !tagged_iterator.. i like that :)

wdyt?

@chalasr
Copy link
Member Author

chalasr commented May 7, 2017

#12269 (comment) :)
that would be nice I think

@ro0NL
Copy link
Contributor

ro0NL commented May 7, 2017

Agree.. then again it adds complexity by creating nested structures (ie. what does !tagged 'foo' do by itself?) It becomes very DSL-ish :) not sure we should go that way.

@chalasr
Copy link
Member Author

chalasr commented May 7, 2017

Agreed

@ro0NL ro0NL mentioned this issue Jul 13, 2017
Merged
@GuilhemN
Copy link
Contributor

The yaml spec defines the !!map tag, also having a !map tag would be confusing imo.

@Vinorcola Vinorcola mentioned this issue Oct 5, 2017
Closed
@chalasr chalasr mentioned this issue Dec 5, 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 Feature
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@nicolas-grekas @ro0NL @xabbuh @GuilhemN @chalasr