One idea is to allow the developer to provide hooks to the mapping process:
[MapTo(typeof(Destination), createDestination: true, postCustomization: true)]
If createDestination is true, a Func<Destination> parameter is created to allow the developer to create it. This may be useful when the destination type has a constructor with parameters. Note that if this is true, the diagnostic that looks for public, no-argument constructors would have to be updated. If postCustomization is true, a Action<Source, Destination> parameter is created to allow the developer to handle complex mapping cases. Here's an example if both of these flags are set to true:
var destination = source.MapToDestination(
() => new Destination(3),
(s, d) =>
{
d.MapThis = s.ToThis;
});
I'm not sure about postCustomization. A developer could simply do this if they want:
var destination = source.MapToDestination();
destination.MapThis = source.ToThis;
I'm basically putting this idea out to think about and come back to later. I guess if you needed to do this customization, having the callback as a parameter "forces" the requirement, rather than having to remember to do the post-processing. But it also feels like it's somewhat unnecessary.
The createDestination flag I think has more value. It's definitely possible that destination types will not always have no-argument constructors, so giving the developer the ability to create the destination has value. However, I'm not sure how this will work with init properties as well, so there be dragons here.
One idea is to allow the developer to provide hooks to the mapping process:
If
createDestinationistrue, aFunc<Destination>parameter is created to allow the developer to create it. This may be useful when the destination type has a constructor with parameters. Note that if this istrue, the diagnostic that looks for public, no-argument constructors would have to be updated. IfpostCustomizationistrue, aAction<Source, Destination>parameter is created to allow the developer to handle complex mapping cases. Here's an example if both of these flags are set totrue:I'm not sure about
postCustomization. A developer could simply do this if they want:I'm basically putting this idea out to think about and come back to later. I guess if you needed to do this customization, having the callback as a parameter "forces" the requirement, rather than having to remember to do the post-processing. But it also feels like it's somewhat unnecessary.
The
createDestinationflag I think has more value. It's definitely possible that destination types will not always have no-argument constructors, so giving the developer the ability to create the destination has value. However, I'm not sure how this will work withinitproperties as well, so there be dragons here.