Skip to content

[DependencyInjection] Always autowire the constructor #21306

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

Merged
merged 1 commit into from
Jan 16, 2017

Conversation

dunglas
Copy link
Member

@dunglas dunglas commented Jan 16, 2017

Q A
Branch? master
Bug fix? no
New feature? no
BC breaks? no (because method autowiring has been introduced in 3.3)
Deprecations? no
Tests pass? yes
Fixed tickets n/a
License MIT
Doc PR n/a

Always try to autowire the constructor even if it has not been configured explicitly. It doesn't make sense to autowire some methods but not the constructor. It will also allow to write shorter definitions when using method autowiring:

services:
    Foo\Bar: { autowire: ['set*'] }

instead of

services:
    Foo\Bar: { autowire: ['__construct', 'set*'] }

@dunglas dunglas force-pushed the autowiring_construct_default branch from 3dc98ce to be3d11f Compare January 16, 2017 15:27
Copy link
Member

@nicolas-grekas nicolas-grekas left a comment

Choose a reason for hiding this comment

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

👍

@nicolas-grekas nicolas-grekas added this to the 3.3 milestone Jan 16, 2017
@fabpot
Copy link
Member

fabpot commented Jan 16, 2017

Looks like a slippery slope here :)

What if my config is:

services:
    Foo\Bar: { autowire: ['setLogger'] }

@dunglas
Copy link
Member Author

dunglas commented Jan 16, 2017

The constructor will be autowired if it exists. If it's not wanted, it's weird to use autowire instead of a call.

@nicolas-grekas
Copy link
Member

I agree with @dunglas: autowiring has to wire the constructor - and optionally the setters.
Having to state:

services:
    Foo\Bar: { autowire: ['__construct', 'setLogger'] }

looks like unneeded boilerplate to me, that people will forget most of the time. There is always a constructor to wire. We don't need to handle the case for one wanting to autowire the setters but wire manually the contructor, because by doing so, one already went out of autowire-land.

@fabpot
Copy link
Member

fabpot commented Jan 16, 2017

Thank you @dunglas.

@fabpot fabpot merged commit be3d11f into symfony:master Jan 16, 2017
fabpot added a commit that referenced this pull request Jan 16, 2017
…(dunglas)

This PR was merged into the 3.3-dev branch.

Discussion
----------

[DependencyInjection] Always autowire the constructor

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | no
| New feature?  | no
| BC breaks?    | no (because method autowiring has been introduced in 3.3)
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | n/a
| License       | MIT
| Doc PR        | n/a

Always try to autowire the constructor even if it has not been configured explicitly. It doesn't make sense to autowire some methods but not the constructor. It will also allow to write shorter definitions when using method autowiring:

```yaml
services:
    Foo\Bar: { autowire: ['set*'] }
```

instead of

```yaml
services:
    Foo\Bar: { autowire: ['__construct', 'set*'] }
```

Commits
-------

be3d11f [DependencyInjection] Always autowire the constructor
@fabpot fabpot mentioned this pull request May 1, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants