-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
Adds MatchConstructorParametersWithUnderscores #1786
Conversation
Merge this pleeeaaaasse |
Please merge this |
Would be great if merged, thanks |
I have been thinking about this one (due to the bumps), mostly wondering: "do we actually need the extra properties?" Help me reason here; the current scenario is that if there are underscores and consequently no match, then today: such code would fail. As long as we're only changing "failing code to working code", I don't think we need the granular properties, and the pre-existing Thoughts? Is there any scenario in which this could change working code to become "not working" or "works differently" ? I'm not sure there is, as long as exact matches are tested first, and normalized matches tested second. |
that might mean that the preferred option is for |
For me that looks logical. Leave the same variable name, and just exact match + check underscores if setting is true. But I'm open to other options as well. |
I just don't want to have to use underscores for the parameter names in my constructors. If it is implemented as the default behavior without a specific property for just constructors or if it is implemented with a specific property for constructors doesn't matter to me, I think both works. I think you are saying that it is unnecessary to add the extra property when it could be the default behavior (given the existing |
Yep; I'll take a look ASAP and see if I can validate the behaviour without this setting; if it is what I think, I'll take on the work to tweak the PR (preserving credit) to remove the extra properties, which I believe we can side step. |
I've validated to my satisfaction that we can add this without the additional settings, since any scenario affected currently fails as:
I'll see about tweaking the PR |
That's nice, it is even better without the additional setting, like you said |
This PR combined and extended in #1947 |
Resolves #818.
Adds the static
MatchConstructorParametersWithUnderscores
property forDefaultTypeMap
which allows matching columns containing underscores to constructor parameters (eg.user_id
matchesuserId
).This commit also renames
MatchNamesWithUnderscores
toMatchFieldsAndPropertiesWithUnderscores
for clarity.MatchNamesWithUnderscores
is marked as obsolete and simply maps toMatchFieldsAndPropertiesWithUnderscores
.