Add ability to specify own naming convention

[StasPerekrestov]

Would it be possible to allow Mapperly users to specify their own naming convention?

Mapperly provides a way to have 2 mapping strategies only, however, there could be use cases when it's insufficient.

For instance, when integration with an "old" SOAP-based system happens, the code generated by xsd.exe/svcutil could have
suffixes/prefixes for every property, e.g. XYZ_FIRST_NAME. As you can see, the mapping might need to address prefixes, snake cases, and capitalization differences.
What if Mapperly allows specifying strategy type explicitly?

[Mapper(PropertyNameMappingStrategyType = typeof(MyPropertyMappingStrategyType))]
public partial class CarMapper
{
    public partial CarDto ToDto(SOAP_CAR_DTO car);
}

Thank you.

[latonz]

The problem with this is that the property mapping has to be done at compile time. This would mean that the property naming strategy code would have to be run at compile time, which would probably have a large performance impact and would probably also be unexpected (it is not intuitive to think of running the user code at compile time instead of at runtime).
I still need to think about this, but at the moment I think additional naming strategies provided by Mapperly would be a better approach here (with options for prefix, suffix, ...), unless there is a way to achieve user-implemented naming strategies in a clean and performant way.

[TimothyMakkison]

I still need to think about this, but at the moment I think additional naming strategies provided by Mapperly would be a better approach here (with options for prefix, suffix, ...), unless there is a way to achieve user-implemented naming strategies in a clean and performant way.

Imo this seems like a reasonable addition, it shouldn't be too hard to add PropertyNameMappingStrategy.CaseInsensitiveKebabCase & PropertyNameMappingStrategy.CaseSensitiveKebabCase. I'd prefer this over letting the user define their own naming convertion. Are there any other strategies we could add? I wonder what Automapper and Mapster support.

Would it be possible to allow Mapperly users to specify their own naming convention?

I think it it would be possible to add this without causing any performance issues. We could define a public interface with the relevant methods and use your method to pass classes implementing it to Mapperly. We'd have to add a check to ensure that the type implements the interface and has a parameterless constructor.

I'm not sure how much demand there is for a user defined strategy. I'd prefer to avoid running user code at compile time 😄

public class MapperAttribute
{
   // other properties

    public Type PropertyNameMappingStrategyType { get; set; }
}

public interface IPropertyNameMappingStrategy
{
    string[] Split(string names);

    IEqualityComparer<string> Compare { get; }
}

[latonz]

@TimothyMakkison could you elaborate how this could work with the interface without running user code at compile time (which would come with a performance hit)?

[TimothyMakkison]

User implements interface and passes the type, Mapperly constructs the type (similar to AttributeDataAccessor) and uses it to split the members and compare the sub members.

Not sure if this is allowed, it would run user code at compile. How bad do you think the performance hit will be?

[latonz]

How would would you construct the type? The AttributeDataAccessor approach does only work with primitive types.
In the source generator we only have access to Roslyn API‘s, not to be confused with reflection.

[TimothyMakkison]

Yeah you're right 😅 we wouldn't be able to construct the type. Thanks for saving me an hour 😄

[StasPerekrestov]

It looks very reasonable, though I wonder if the approach allows addressing suffixes and prefixes differences.

[TimothyMakkison]

addressing suffixes and prefixes differences.

Could you elaborate on this? Do you want something like _VALUE_ matches Value

[StasPerekrestov]

Sure,
I've been working on integration with some legacy SOAP-based systems.
It has a ton of fields with names starting with GKPR_

GKPR_LIENHLDR_NAME
GKPR_LIENHLDR_ADDRESS1
GKPR_LIENHLDR_ADDRESS2
GKPR_LIENHLDR_CITY
GKPR_LIENHLDR_ST
GKPR_LIENHLDR_ZIP_CODE

and I'm mapping them to some other models. Currently, I don't think that it's possible to make Mapperly to generate automatically
mappings to a DTO that uses the Pascal case naming convention.

LienhldrName
LienhldrAddress1
LienhldrAddress2
LienhldrCity
LienhldrSt
LienhldrZipCode

In the other systems, I saw that property names may have their type name as a suffix.

FIRST_NAME_STR
DOB_DATE
PURCHACE_YEAR_INT

Having more control over the mapping convention makes the whole experience much more powerful.
At least I can make the mapping logic ignore some parts of property names during the properties matching process.
Thank you.

[ToovR]

Hi, I needed an option to ignore underscore too. So, I forked the project and kind of implemented it (https://github.com/ToovR/mapperly).
I don't know if it is bullet proof but it is working for me.
The usage is :

// Will both ignore case and underscores
[Mapper(
    PropertyNameMappingStrategy = PropertyNameMappingStrategy.UnderscoreIgnore | PropertyNameMappingStrategy.CaseInsensitive
)]
public static partial class CarMapper
{
    [MapProperty(nameof(Car.Manufacturer), nameof(CarDto.Producer))] // Map property with a different name in the target type
    public static partial CarDto MapCarToDto(Car car);
}

[szyb]

I was just about to write an idea to add support for custom conventions (or kind of new PropertyNameMappingStrategy value that will handle it) , but it is already here. My case is (almost) the same as yours @StasPerekrestov. I need to map properties in snake case to pascal cast (and vice versa) and currently cannot be done easily. Need to map every single property with underscore.

Have you been thinking about custom split char, so user can define it in attribute level? However I cannot see any other useful examples than underscore character. In the same way define prefix and suffix to ignore.

[latonz]

Would an API like this #619 (comment) support your use-case?

[szyb]

Yes, I think so. Using it I could rename properties by replacing "_" to "" (string.Empty), so they should match each other. I'm only concerned about case sensitivity. Would it work to match LINE_NUMBER with LineNumber by using this declaration: [Mapper(PropertyNameMappingStrategy = PropertyNameMappingStrategy.CaseInsensitive)] ?

[latonz]

Yes, that should work if we decide to implement that api.