Skip to content
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.

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

[DI] Deprecate autowiring-types in favor of aliases #21494

Merged
merged 1 commit into from Feb 1, 2017

Conversation

nicolas-grekas
Copy link
Member

@nicolas-grekas nicolas-grekas commented Feb 1, 2017

Q A
Branch? master
Bug fix? no
New feature? yes
BC breaks? no
Deprecations? yes
Tests pass? yes
Fixed tickets #21351, #19970, #18040, #17783
License MIT
Doc PR symfony/symfony-docs#7445

https://github.com/symfony/symfony/pull/21494/files?w=1
This PR deprecates autowiring-types and replaces them by plain aliases.
ping @dunglas @weaverryan

Eg instead of

<service id="annotations.reader" class="Doctrine\Common\Annotations\AnnotationReader" public="false">
    <autowiring-type>Doctrine\Common\Annotations\Reader</autowiring-type>
</service>

just do:

<service id="annotations.reader" class="Doctrine\Common\Annotations\AnnotationReader" public="false" />
<service id="Doctrine\Common\Annotations\Reader" alias="annotations.reader" public="false" />

@weaverryan
Copy link
Member

@nicolas-grekas Haha... I really like this simplification... but I don't understand how it works! :) Is there some significance to the service id matching the autowired interface? Otherwise... I would still expect that if I had 10 services for an interface (e.g. LoggerInterface)... that now it would simply appear that I would have 11 services for that interface. Clearly, I'm missing something ;)

@nicolas-grekas
Copy link
Member Author

nicolas-grekas commented Feb 1, 2017

It is very simple: if there is a service named "Foo\BarInterface", then that's the one, when looking to wire a "Foo\BarInterface" type hint.

UPGRADE-3.3.md Outdated
@@ -14,6 +14,8 @@ Debug
DependencyInjection
-------------------

* Autoriwing-types have been deprecated, use aliases instead.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't we add an example here?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

indeed, the example from the pr desc fi

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

example added

@stof
Copy link
Member

stof commented Feb 1, 2017

this is a very elegant solution to the problem, allowing to use third-party services to autowire a type (as your alias can point to any service), and forbidding to explicitly configure the same autowired type twice for different services (as service ids are unique).

So 👍 for me.

@chalasr
Copy link
Member

chalasr commented Feb 1, 2017

Far simpler 👍

@dunglas
Copy link
Member

dunglas commented Feb 1, 2017

Great! 👍

@weaverryan
Copy link
Member

Ha, I missed the change to AutowirePass. Of course, it makes sense! We'll need a docs issue so we can update things.

👍

$definition = $container->findDefinition('templating');
$definition->setAutowiringTypes(array(ComponentEngineInterface::class, FrameworkBundleEngineInterface::class));
$container->setAlias(ComponentEngineInterface::class, 'templating');
$container->setAlias(FrameworkBundleEngineInterface::class, 'templating');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should be private aliases. We don't want to keep these service names in the compiled container

</service>
<service id="Symfony\Component\EventDispatcher\EventDispatcherInterface" alias="event_dispatcher" />
<service id="Symfony\Component\EventDispatcher\EventDispatcher" alias="event_dispatcher" />
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

these should be private aliases

<autowiring-type>Symfony\Component\DependencyInjection\ContainerInterface</autowiring-type>
<autowiring-type>Symfony\Component\DependencyInjection\Container</autowiring-type>
</service>
<service id="service_container" synthetic="true" />
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't this one be removed entirely ? The component already handles it

</service>
<service id="service_container" synthetic="true" />
<service id="Symfony\Component\DependencyInjection\ContainerInterface" alias="service_container" />
<service id="Symfony\Component\DependencyInjection\Container" alias="service_container" />
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

these aliases should be private

</service>
<service id="Symfony\Component\Translation\TranslatorInterface" alias="translator.default" />
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the alias should be translator IMO instead, so that autowiring injects the real translator when using decoration. Otherwise, we loose the profiler integration when using autowiring and someone decorates the main translator alias rather than the private service.

And this alias should also be private (as any alias created purely for autowiring purpose anyway)

UPGRADE-3.3.md Outdated
@@ -14,6 +14,23 @@ Debug
DependencyInjection
-------------------

* Autoriwing-types have been deprecated, use aliases instead.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo here

UPGRADE-4.0.md Outdated
@@ -24,6 +24,23 @@ Debug
DependencyInjection
-------------------

* Autoriwing-types have been removed, use aliases instead.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo here

@nicolas-grekas
Copy link
Member Author

@stof comments addressed, thanks

@stof
Copy link
Member

stof commented Feb 1, 2017

btw, my comment about using private aliases for this is also true for the documentation when writing it

@weaverryan
Copy link
Member

Docs issue created - I added a note on there about your (Stof) "private aliases" comment.

@fabpot
Copy link
Member

fabpot commented Feb 1, 2017

Thank you @nicolas-grekas.

@fabpot fabpot merged commit b11d391 into symfony:master Feb 1, 2017
fabpot added a commit that referenced this pull request Feb 1, 2017
…icolas-grekas)

This PR was merged into the 3.3-dev branch.

Discussion
----------

[DI] Deprecate autowiring-types in favor of aliases

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | yes
| Tests pass?   | yes
| Fixed tickets | #21351, #19970, ~~#18040~~, ~~#17783~~
| License       | MIT
| Doc PR        | symfony/symfony-docs#7445

https://github.com/symfony/symfony/pull/21494/files?w=1
This PR deprecates autowiring-types and replaces them by plain aliases.
ping @dunglas @weaverryan

Eg instead of
```xml
<service id="annotations.reader" class="Doctrine\Common\Annotations\AnnotationReader" public="false">
    <autowiring-type>Doctrine\Common\Annotations\Reader</autowiring-type>
</service>
```

just do:
```xml
<service id="annotations.reader" class="Doctrine\Common\Annotations\AnnotationReader" public="false" />
<service id="Doctrine\Common\Annotations\Reader" alias="annotations.reader" public="false" />
```

Commits
-------

b11d391 [DI] Deprecate autowiring-types in favor of aliases
@nicolas-grekas nicolas-grekas moved this from In Review to Done in Lower entry bar Feb 1, 2017
@theofidry
Copy link
Contributor

@nicolas-grekas shouldn't this be back-ported to 2.8? Autowiring has been introduced there and IIRC there is autowiring-types there as well. It would allow people to never use autowiring-types in the first place and it could be considered as a bug rather than a feature.

@chalasr
Copy link
Member

chalasr commented Feb 1, 2017

@theofidry from semver:

  • Minor version Y (x.Y.z | x > 0)
    It MUST be incremented if any public API functionality is marked as deprecated

@dunglas
Copy link
Member

dunglas commented Feb 1, 2017

@theofidry I don't think so. People using 2.8 LTS should not be annoyed with a deprecation in a patch version. It works well as is. This improvement is really a new feature.

@theofidry
Copy link
Contributor

fair enough

@sstok
Copy link
Contributor

sstok commented Feb 21, 2017


```
Using the attribute "class" is deprecated for the service "2_d44d409a6f8ec9217d33bfd752130a5a50dfdd4314933b690caf9278e3ece37c" which is defined as an alias in "/[..]/rollerworks/search-bundle/src/DependencyInjection/../Resources/config/search_processor.xml". Allowed attributes for service aliases are "alias", "id" and "public". The XmlFileLoader will raise an exception in Symfony 4.0, instead of silently ignoring unsupported attributes: 1x
    1x in SearchProcessorTest::testEmptySearchCodeIsValid from Rollerworks\Bundle\SearchBundle\Tests\Functional
```

Never mind 🙈 class !== id 😅 

@chalasr
Copy link
Member

chalasr commented Feb 21, 2017

@sstok Using public aliases works fine on my side. The exception message make me think it's unrelated. Maybe open an issue showing the failing service definition (from search_processor.xml)?

@sstok
Copy link
Contributor

sstok commented Feb 21, 2017

I used class instead of id for the class 🙂

<service class="Rollerworks\Bundle\SearchBundle\Processor\SearchProcessor" alias="rollerworks_search.http_foundation_search_processor" public="false" />

Should be

<service id="Rollerworks\Bundle\SearchBundle\Processor\SearchProcessor" alias="rollerworks_search.http_foundation_search_processor" public="false" />

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
Development

Successfully merging this pull request may close these issues.

None yet

10 participants