Skip to content

[DI] Suggest typed argument when binding fails with untyped argument #34223

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 14, 2020

Conversation

gudfar
Copy link
Contributor

@gudfar gudfar commented Nov 2, 2019

Q A
Branch? 4.3
Bug fix? yes
New feature? no
Deprecations? no
Tickets #33470
License MIT

I've added a condition that looks for arguments and if the typehint doesn’t match, throws an InvalidArgumentException

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.

Here is a code review, but before fixing it: this will break configurations that target different arguments when the type is here or not. To them, the exception will be a false positive.

A safer approach might be to improve the message where the current exception is thrown. Because we might have less context there, the message might be more generic - but that's the point of not triggering false positives and still giving some hint.

@gudfar
Copy link
Contributor Author

gudfar commented Nov 5, 2019

@nicolas-grekas

Here is a code review, but before fixing it: this will break configurations that target different arguments when the type is here or not. To them, the exception will be a false positive.

I guess it shouldn't break, because exception will trigger only if we have different argument type in binding and in constructor. But I also don’t like throwing an exception in this place I can suggest to add error message. It will look like this http://joxi.net/YmEyjBYtw5O7Bm
WDYT?

@nicolas-grekas
Copy link
Member

nicolas-grekas commented Nov 5, 2019

Let's give it a try :)

Copy link
Member

@derrabus derrabus left a comment

Choose a reason for hiding this comment

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

We should add a test.

@nicolas-grekas nicolas-grekas changed the title [DependencyInjection] Bind with type is broken if no typehint used for constructor parameter [DI] Suggest typed argument when binding fails with untyped argument Dec 15, 2019
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.

I pushed an alternative implementation. I also removed the case where both a binding and an argument have a type but they don't match: I'm not sure we should suggest these - it's not the job of bindings to decide for the API of a class.

@OskarStark please confirm that this fixes your concern.

@OskarStark
Copy link
Contributor

Thank you Nicolas I am able to test this in January but from the code pov it looks good👍🏻

@nicolas-grekas
Copy link
Member

friendly ping @OskarStark

@nicolas-grekas
Copy link
Member

Thank you @gudfar.

nicolas-grekas added a commit that referenced this pull request Jan 14, 2020
…d argument (gudfar)

This PR was merged into the 4.3 branch.

Discussion
----------

[DI] Suggest typed argument when binding fails with untyped argument

| Q             | A
| ------------- | ---
| Branch?       |  4.3
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Tickets       |  #33470
| License       | MIT

I've added a condition that looks for arguments and if the typehint doesn’t match, throws an `InvalidArgumentException`

Commits
-------

0e92399 [DI] Suggest typed argument when binding fails with untyped argument
@nicolas-grekas nicolas-grekas merged commit 0e92399 into symfony:4.3 Jan 14, 2020
This was referenced Jan 21, 2020
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