We are hard-coded to have a certain expectation of ctor parameter names to property names in immutable objects (e.g. events).
The ctor parameter is camelCase and the property is PascalCase. If it does not do this then things will not be matched up and you will probably get very ugly / hard to understand null reference errors (or even worse, the things can be null and then we are dealing with wrong data!).
To begin with, we need a build rule that checks this and tells the user if there is a problem with the ctor parameter to property names.
Longer term, we need to decide if we are going to support different matching strategies.
We are hard-coded to have a certain expectation of ctor parameter names to property names in immutable objects (e.g. events).
The ctor parameter is camelCase and the property is PascalCase. If it does not do this then things will not be matched up and you will probably get very ugly / hard to understand null reference errors (or even worse, the things can be null and then we are dealing with wrong data!).
To begin with, we need a build rule that checks this and tells the user if there is a problem with the ctor parameter to property names.
Longer term, we need to decide if we are going to support different matching strategies.
┆Issue is synchronized with this Asana task