[DependencyInjection] Rename "exclude tag" to "resource tag"

[kbond]

Q	A
Branch?	7.3
Bug fix?	no
New feature?	no
Deprecations?	no
Issues	Follow up to #59704
License	MIT

I find $definition->addExcludedTag('app.model') and $containerBuilder->findExcludedServiceIds('app.model') unintuitive. If feels like your excluding something from the DI container but in fact, your registering it, but in a "different way". The fact that it's an excluded service is just a side-effect. This is especially weird when the tag has attributes ($definition->addExcludedTag('app.model', ['connection' => 'default'])).

Totally open for a name other than "resource".

[GromNaN]

Resource is more in line with the name we were searching in #59704 (comment)

But in the ContainerBuilder, a resource is already a file or directory path to watch. Isn't there a risk of confusion?

[kbond]

Isn't there a risk of confusion?

Yeah, that is unfortunate... "resource" also makes me think it could be non-classes (js,md,jpg files).

[weaverryan]

Naming (data model?)

We shouldn't bike shed too much (I'm already ok with this PR and "resource"), but I'd also suggest:

$definition->addDataModelTag('entity', ['connection' => 'default']);

What we know is that the class is not a service: it's a class that holds data: a "data model" class. Maybe it's an entity, maybe a DTO made by the user, or an ApiResource. This "data model" idea seems to cover these cases.

The Container's new Superpower

More generically, it seems like we're adding a new superpower to the container:

1. it can instantiate services
2. it can return a list of "data model" classes of some type (e.g. entity)

Is that correct?

[kbond]

addDataClassTag()?

[chalasr]

The word Resource is really clever in this context, I think we should not exclude it from the discussion :)
But the fact this removes the explicit exclude from the method name + the possible confusion with resource tracking this would introduce as-is makes me hesitant too.

[chalasr]

Not blocking, but I still have the same feeling as in #59704:

Trying to find a generic term for grouping some classes through the container then making them excluded looks like a dead end as there are many possible reasons for a class not to be registered as service and certainly ones we don't even imagine. Excluded services however is a concept we already have

[nicolas-grekas]

I'm for "resource", this is the most generic term. The confusion about config's resources isn't one I would care much about: both things we're talking about are quite advanced concepts that need teaching anyway.

[chalasr]

For the remaining point about the excluding behavior being no longer obvious, what about

• $container->addExcludedResourceTag()
• Or ->excludeResource($tag)
• Or ->excludeTaggedResource()?

[nicolas-grekas]

It's excluded from being a service, but still managed as a resource for invalidating the container.
I think we're safe not having "excluded": this is a service container, not a resource registry, so making something a resource already excludes it from the DIC IMHO, conceptually.

[GromNaN]

still managed as a resource for invalidating the container.

That convinced me. The definition is a "resource" used during container build.

[chalasr]

Fair enough 👍

[nicolas-grekas]

Thank you @kbond.