Multiple ideas to consider

[mshgh]

I am putting all my ideas into single post for initial sorting from direct yes let's create an issue or interesting let's have (separate) discussion till no way, won't do.

1. custom default Mapper configuration. Common approach would be to allow MapperAttribute applicable on Assembly

2. partial explicit interface implementation support. I think we are almost there just from some reason in the generated code is added private member access modifier breaking compilation

   // generated code
   internal sealed partial class Foo {
      private partial DstType IFoo.Mapping(SrcType src) { ...
   }

3. as I realized in User implemented mapping methods ignored when return type is string? #193 that in non-static Mappers are custom mappings ignored if static

   [Mapper]
   internal sealed partial class Foo {
      private /*static*/ DstType Mapping(SrcType src) { ... } // used
      private static DstType Mapping(SrcType src) { ... } // ignored
   }

4. automatically generated interface. From all public methods of mapper Foo generate interface IFoo. My initial approach here was I want to have mappers injected to my business logic classes so I need interface (and I created them), but then I was thinking do I really need ifc? Why not to inject mapper as a class directly. So not 100% sure about this, but still worth mentioning.

5. DI integration support - auto-discovery and register all Mappers. I have end up with this massive one-liner. I guess it will be cool to have this part your solution. Maybe as another nuget Riok.Mapperly.Extensions.Microsoft.DependencyInjection as people usually do? Just to prevent everybody to re-invent it.

   // my approach
   private static IServiceCollection AddMapperly(this IServiceCollection services, params Type[] types) => types
     .Select(type => type.Assembly).Distinct()
     .SelectMany(assembly => GetLoadableTypes(assembly))
     .Where(type => type.IsClass && type.GetCustomAttributes(typeof(MapperAttribute), false).Length > 0)
     .Aggregate(services, (services, classType) => classType.GetInterfaces().Count() == 0
       ? services.AddTransient(classType)
       : classType
         .GetInterfaces()
         .Aggregate(services, (services, interfaceType) => services.AddTransient(interfaceType, classType))
     );
   
   private static IEnumerable<Type> GetLoadableTypes(Assembly assembly) {
     try { return assembly.GetTypes(); }
     catch (ReflectionTypeLoadException e) { return e.Types.Where(t => t != null)!; }
   }  

6. Void mapping method returning 😄 destination. I guess we can be good here with a convention that methods with following signature are meant to hydrate provided instance. I don't think this would replace the void variant, but allow for alternative

   [Mapper]
   internal sealed partial class Foo {
      public partial DstType Mapping(SrcType src, DstType dst);
      // today I need to do it manually
      public DstType Mapping(SrcType src, DstType dst) {
          Mapping(src, dst);
          return dst;
      }
   }

7. alternative multi parameter signature for Attributes. Just for a bit more concise declaration.

   [Mapper]
   internal sealed partial class Foo {
      [MapperIgnoreTarget("Prop1", "Prop2")]
      [MapProperty(("Foo", "Bar"), ("Baz", Ban"))]
      public partial DstType Mapping(SrcType src, DstType dst);
   }

8. manual work saving features
   a. allow for additional parameters in mapping method and based on the name&type-matching set them to the target

   [Mapper]
   internal sealed partial class Foo {
      public partial DstType Mapping(SrcType src);
      // let's auto-generate this
      public /*partial*/ DstType Mapping(SrcType src, DstType dst, SomeOtherType bar) {
        var dst = Mapping(src);
        dst.Bar = bar;
        return dst;
      }
   }

   b. collections support

     [Mapper]
     internal sealed partial class Foo {
        public partial DstType Mapping(SrcType src);
        // let's auto-generate this
        public /*partial*/ IEnumerable<DstType> Mapping(IEnumerable<SrcType> srcs) {
          foreach(var scr in srcs) {
            yield return Mapping(src);
          }
        }
     }
     ```

Sorry, for such a lengthy post. I hope at least part of it will be for any use to you. And I have to tell you I really love this component!

P.S. One question on the MapperAttribute in can be applied to an interface, but I haven't found what this is good for neither in the docs neither by experimenting.

EDIT: changed to numbered list

[latonz]

Thank you for your ideas.

1. Custom default mapper configuration

Sounds like a nice idea. Created #201

2. Partial explicit interface implementation

I don't really get what a real world use-case is for that one. Can you provide concrete use-case examples?

3. Support static user implemented mapping methods in non-static mappers

Created #200

4. Automatically generated mapper interfaces

I don't think Mapperly should automatically generate interfaces. I don't see a reason to use interfaces on the mappers, as the implementation should not need to be mocked or replaced with another implementation. What's the reason you want to use interfaces over the classes?

5. DI Registration support

Created #202

6. Void mapping method returning target

We may implement this later. However, we don't think this has a high priority for now. Also it adds more and more options for the user on how to define mapping methods which will increase the overall complexity.

7. Alternate syntax for the MapProperty attribute

Touples are not valid attribute ctor types.

8a. Additional mapping method parameters

Already tracked in #103

8b. Implicit IEnumerables support

When defined explicitly, this does already work. If these methods would be added automatically, the generated code will be bloated by a lot of methods which are probably never used...

[mshgh]

Thank you for reviewing the ideas and sorry for duplicates.
I didn't realize the 8b is already there. This is cool, and this is exactly what I meant. No up-front generated code.

I think we can drop the interfaces related part. The more I think about this the more this looks like overkill.

[pchasco]

I don’t see a compelling reason why a mapper would need to be mocked, but even if someone had a need for it, that could be accomplished by making the mapping methods virtual so that they can be overridden with a mocked/faked implementation.