Remove ConstructProjectionUsing

[lbargaoanu]

Replace it with expression based ConstructUsing. It seems like a good time, as we've already bumped the version. But I guess it's debatable. Why wouldn't the same apply to ProjectUsing?

[jbogard]

The general argument against is that not every ConstructUsing can be represented as an expression.

Another option would be to remove the ConstructProjectionUsing (really any expression-specific method) and instead have an overload:

        IMappingExpression<TSource, TDestination> ConstructUsing(Expression<Func<TSource, TDestination>> ctor);
        IMappingExpression<TSource, TDestination> ConstructUsing(Func<TSource, ResolutionContext, TDestination> ctor);

If you want to use a complex Func, you need to use the more complex overload. I'd like to go one step further and remove ResolveUsing but those have an additional complication in that their results are mapped.

[lbargaoanu]

Yes, but I was trying to say, ProjectUsing vs ConvertUsing, isn't it the same?

[jbogard]

Ah, yes. Those two as well.

[jbogard]

So would we remove the "ResolveUsing" overloads that just map via Func to collapse to MapFrom? Save ResolveUsing for actual resolvers?

[lbargaoanu]

You mean MapFrom(Func), I suppose (not MapFrom(Expression)). That makes sense, but I think it's too big of a change. I guess we could provide some built in extension methods, but that would defeat the purpose as most people would probably use those.

[jbogard]

To summarize, we'd have expression-based methods where we can use that configuration easily for both ProjectTo and Map.

Conversions

Old

void ProjectUsing(Expression<Func<TSource, TDestination>> projectionExpression);
void ConvertUsing(Func<TSource, TDestination> mappingFunction);
void ConvertUsing(Func<TSource, TDestination, TDestination> mappingFunction);
void ConvertUsing(Func<TSource, TDestination, ResolutionContext, TDestination> mappingFunction);
void ConvertUsing(ITypeConverter<TSource, TDestination> converter);
void ConvertUsing<TTypeConverter>() where TTypeConverter : ITypeConverter<TSource, TDestination>;

Proposed

void ConvertUsing(Expression<Func<TSource, TDestination>> mappingExpression);
void ConvertUsing(Func<TSource, TDestination, TDestination> mappingFunction);
void ConvertUsing(Func<TSource, TDestination, ResolutionContext, TDestination> mappingFunction);
void ConvertUsing(ITypeConverter<TSource, TDestination> converter);
void ConvertUsing<TTypeConverter>() where TTypeConverter : ITypeConverter<TSource, TDestination>;

Construction

Old

IMappingExpression<TSource, TDestination> ConstructUsing(Func<TSource, TDestination> ctor);
IMappingExpression<TSource, TDestination> ConstructProjectionUsing(Expression<Func<TSource, TDestination>> ctor);
IMappingExpression<TSource, TDestination> ConstructUsing(Func<TSource, ResolutionContext, TDestination> ctor);

Proposed

IMappingExpression<TSource, TDestination> ConstructUsing(Expression<Func<TSource, TDestination>> ctor);
IMappingExpression<TSource, TDestination> ConstructUsing(Func<TSource, ResolutionContext, TDestination> ctor);

Member mapping (this is a stretch)

Old

void MapFrom<TSourceMember>(Expression<Func<TSource, TSourceMember>> sourceMember);
void MapFrom(string property);
void ResolveUsing<TResult>(Func<TSource, TResult> resolver);
void ResolveUsing<TResult>(Func<TSource, TDestination, TResult> resolver);
void ResolveUsing<TResult>(Func<TSource, TDestination, TMember, TResult> resolver);
void ResolveUsing<TResult>(Func<TSource, TDestination, TMember, ResolutionContext, TResult> resolver);
void ResolveUsing<TValueResolver>() where TValueResolver : IValueResolver<TSource, TDestination, TMember>;
void ResolveUsing<TValueResolver, TSourceMember>(Expression<Func<TSource, TSourceMember>> sourceMember) where TValueResolver : IMemberValueResolver<TSource, TDestination, TSourceMember, TMember>;
void ResolveUsing<TValueResolver, TSourceMember>(string sourceMemberName) where TValueResolver : IMemberValueResolver<TSource, TDestination, TSourceMember, TMember>;
void ResolveUsing(IValueResolver<TSource, TDestination, TMember> valueResolver);
void ResolveUsing<TSourceMember>(IMemberValueResolver<TSource, TDestination, TSourceMember, TMember> valueResolver, Expression<Func<TSource, TSourceMember>> sourceMember);

Proposed (?)

void MapFrom<TResult>(Expression<Func<TSource, TResult>> resolver);
void MapFrom(string property);
void MapFrom<TResult>(Func<TSource, TDestination, TResult> resolver);
void MapFrom<TResult>(Func<TSource, TDestination, TMember, TResult> resolver);
void MapFrom<TResult>(Func<TSource, TDestination, TMember, ResolutionContext, TResult> resolver);
void ResolveUsing<TValueResolver>() where TValueResolver : IValueResolver<TSource, TDestination, TMember>;
void ResolveUsing<TValueResolver, TSourceMember>(Expression<Func<TSource, TSourceMember>> sourceMember) where TValueResolver : IMemberValueResolver<TSource, TDestination, TSourceMember, TMember>;
void ResolveUsing<TValueResolver, TSourceMember>(string sourceMemberName) where TValueResolver : IMemberValueResolver<TSource, TDestination, TSourceMember, TMember>;
void ResolveUsing(IValueResolver<TSource, TDestination, TMember> valueResolver);
void ResolveUsing<TSourceMember>(IMemberValueResolver<TSource, TDestination, TSourceMember, TMember> valueResolver, Expression<Func<TSource, TSourceMember>> sourceMember);

The main idea is to consolidate conversion, construction, and member mapping configuration methods. This makes it more obvious that you shouldn't mix and match.

[lbargaoanu]

Updated with ResolveUsing.

[lbargaoanu]

But the problem here is that we might break a lot of projections when going from Func to Expression. What used to apply only for Map will apply for ProjectTo too now.

[jbogard]

I'm not suggesting breaking ProjectTo, but this will break some Func based versions of the overloads. Mainly, if you're using a Func-based version that's getting replaced with Expression, you must use expressions now. Whether or not that expression can be used by ProjectTo is different.

What this will explicitly prevent though is people wanting to use different configurations for ProjectTo and Map, which is fine by me.

If you have a complex lambda statement that can't be converted to an expression, you'll just need to use the overloads that allow Func.

[jbogard]

Also, I'm fine with the ResolveUsing changes. That makes sense - those overloads use an object rather than func.

[lbargaoanu]

Yes, but the end result is some code used to work, you upgrade AM, it compiles, and it no longer works for ProjectTo because the older version didn't use it (still works for Map). Right? :) So I'm not sure of the impact here.

[jbogard]

I don't think so - the old version you'd have to use ConstructProjectionUsing for example, and that method would be gone. It'd only affect people that used both methods. Which I don't think we'd want to support, separate config for different mapping execution strategies.

If you were using both, you now have to choose. I'm OK with that.

[lbargaoanu]

I have ConstructUsing(Func). That one becomes CostructUsing(Expression) after the upgrade. Let's say it compiles. The new version will use it for ProjectTo, but EF doesn't support that. The same applies to ConvertUsing. I think :)

[jbogard]

It's possible - which would only break people that supplied both ConstructUsing and ConstructProjectionUsing. For those folks, which is weird, they'd need to adjust their ConstructUsing to use the more complex Func-based overload.

It won't break anyone at runtime today. Only break at compile-time. Anyone working at runtime today should continue to work.

If they had ConvertUsing(Func) and it now works with expression, then decided to use EF, it could break. But that's true with ConvertProjectionUsing today - you could pass in a legal expression but illegal EF expression.

So the impact is twofold, I think:

• It is a breaking compile change for those using Expression-based methods
• Lambda-statement based Func that now use Expression will need to switch overloads to the more complex versions that accept more params

[lbargaoanu]

Pretty much. We disagree on details. In my example, ProjectTo ignores ConstructUsing (ConstructProjectionUsing is not configured), so it worked in the older version. But after we remove ConstructProjectionUsing we have to use ConstructUsing(Expression), so ProjectTo might no longer work.