-
-
Notifications
You must be signed in to change notification settings - Fork 70
Required but nullable arguments should be required to be specified in the config #271
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
Comments
That makes sense. I'll try to add a deprecation notice for this situation in version 3.1, which should just warn about the changes in 4.0. |
Awesome, thank you! |
I wonder if it shouldn't work that way for objects too? Ie. |
Yeah, if |
dg
added a commit
that referenced
this issue
Dec 14, 2021
… is required (for classes, experimental) [Closes #271]
dg
added a commit
that referenced
this issue
Dec 14, 2021
… is required (for classes, experimental) [Closes #271]
dg
added a commit
that referenced
this issue
Dec 14, 2021
… is required (for classes, experimental) [Closes #271]
dg
added a commit
that referenced
this issue
Dec 15, 2021
… is required (for classes, experimental) [Closes #271]
dg
added a commit
that referenced
this issue
Dec 15, 2021
… is required (for classes, experimental) [Closes #271]
dg
added a commit
that referenced
this issue
Dec 15, 2021
… is required (for classes, experimental) [Closes #271]
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Let's say we have a constructor that looks like this:
And we have a service config that looks like this:
In this case nette/di will autowire the
null
value into this constructor parameter. But the the constructor parameter is required for a reason - I want the user to specify it. Omitting it is dangerous because the library can't assume that the user wantsnull
in there, because they might not even know that I want them to specify the value. I want the user to explicitly pass a value.I realize this is a big BC break, but maybe the behaviour could be opt-in with some feature toggle before making it mandatory in the next major version.
The text was updated successfully, but these errors were encountered: