Invoke and extend other mappers

[jakoss]

I just came here to say thank you sir, I was waiting for this so much!

I have one question though - do you plan to support dependency between mappers? For example I have a DateConversionMapper with, well, date conversions and then I want to create domain specific mapper that relies on the mappings from DateConversionMapper. MapStruct supports this by uses attribute property: https://mapstruct.org/documentation/stable/reference/html/#invoking-other-mappers

[latonz]

Thank you!

This is currently not supported. However, using inherited methods from a base class is supported (inheriting methods with implementation bodies are already supported, partial / generated base class mapping methods are planned, see #38). The following works with the current version of Mapperly:

class DateMapper
{
    protected DateOnly DateTimeToDateOnly(DateTime dt) => DateOnly.FromDateTime(dt);
}

[Mapper]
partial class DtoMapper : DateMapper
{
    public partial CarDto ToDto(Car car);
}

In this sample, when the DtoMapper needs to map a DateTime to a DateOnly, Mapperly will use the DateMapper.DateTimeToDateOnly method.
You can also call other mappers manually inside of a mapper:

[Mapper]
class DateMapper
{
    public partial DateDto ToDateDto(DateTime dt);
}

[Mapper]
partial class DtoMapper : DateMapper
{
    private readonly DateMapper _dateMapper = new();

    public partial CarDto ToDto(Car car);

    private DateDto ToDateDto(DateTime dt) => _dateMapper.ToDateDto(dt);
}

or split your mapper into several files with the partial class feature.
Referencing and "including" other mappers via attribute (eg. [Mapper(Uses = typeof(DateMapper)]) is pretty complex, which is why we deprioritized that feature and won't implement it in the near future.

[jakoss]

It's for sure better than nothing, but I can already see how inheritance may go haywire on bigger projects with multiple projects with non-trivial dependency trees. Still, I'll test that out on some smaller projects and for sure will keep an eye on that project :)

[latonz]

This is now implemented as "use external mappings" ([UseMapper] and [UseStaticMapper<>]) and released in 3.2.0-next.1. See docs.

[mshgh]

Can I ask what makes this feature complex? From the 10 000 foot view this looks straightforward with all the building boxes at hand. All what seems to be necessary is to add every method from the Type which qualifies as potential custom mapping method into a pool of custom mapping methods. For static methods they can be just called, for member methods, yes, mapper instance needs to be created. It means only classes with parameterless constructors can be used as external mapper. Or do they? My ideal world solution would go one step further ;)

Let's consider this. BTW the referenced mappers do not need MapperAttribute it can be simple mundane classes with methods...

[Mapper]
[UseMapper(typeof(SomeMapper), typeof(OtherMapper))]
[InjectMapper(typeof(ExtraMapper), typeof(CoolMapper))]
internal sealed partial class Foo {
   public partial Dst Mapping(Src src);
}

// would generate
internal sealed partial class Foo {
   private readonly ExtraMapper injectedMapper1;
   private readonly CoolMapper injectedMapper2;

   public Foo(ExtraMapper injectedMapper1, CoolMapper injectedMapper2) {
     this.injectedMapper1 = injectedMapper1;
     this.injectedMapper2 = injectedMapper2;
   }

   public partial Dst Mapping(Src src) {
      var externalMapper1 = new SomeMapper();
      var dst = new Dst() { A = src.A, B = src.B };
      dst.Foo = OtherMapper.Mapping(src.Foo); // static method mapping
      dst.Bar = externalMapper1.Mapping(src.Bar);
      dst.Baz = externalMapper1.Mapping(src.Baz); // mapper re-used
      dst.Bax = this.injectedMapper1.Mapping(src.Bax);
      dst.Ban = this.injectedMapper2.Mapping(src.Ban);
      return dst;
   }
}

[latonz]

IMO there is no need for the InjectMapper attribute, as one could simply define the ctor and fields and annotate the fields.
This feature adds quite a bit of complexity to the Mapperly codebase and also adds new api surface to the user which increases the complexity there. We may reconsider this at a later point, but currently the priority of other features is higher to us.

[PaulVrugt]

So if I have a generic converter for users, and another for user groups, and I have to map an entity that has both a user and a usergroup property, I am stuck. Since I can only inherit from a single class. Unless I put all my generic converters in a single class, and let everything inherit from this. But this prevents me from inheriting from something else.

I am very enthusiastic about this library, but not supporting this is quite a hurdle

Edit:
Never mind, this library is even more cool than I thought. It is very smart. My compliments