You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I understand that this can currently be solved with user mapping methods in the mapper, but it seems that sometimes this could be avoided with the proposed solution.
I think the rule by which this should work should be simple - it works when the method name ends with the target name
The text was updated successfully, but these errors were encountered:
The 'magic' that Mapperly handles becomes more and more with every new feature. This would add additional complexity to Mapperly and add more magic (especially the variable prefix). I think for most of these mappings it can be solved quite simple by replacing the source method with a property getter (e.g. public DateTime LastDay => AllDates.Max()).
I think for most of these mappings it can be solved quite simple by replacing the source method with a property getter
This is true, but the source type is not always editable, it may be provided by library code. In our not very large project, we came across this only once, when we integrated with a third-party service.
Based on the lack of similar requests, this is a very rare situation.
I think increasing complexity is a natural process for all evolving products. In any case, the decision is yours.
It seems that in some cases it would be convenient to have automatic conversion by calling a method on the source object, for example:
could produce:
or
could produce:
I understand that this can currently be solved with user mapping methods in the mapper, but it seems that sometimes this could be avoided with the proposed solution.
I think the rule by which this should work should be simple - it works when the method name ends with the target name
The text was updated successfully, but these errors were encountered: