Redundant Mapping Method?

Mar 20, 2011 at 3:16 AM

I have this ordinary method:

[ExpressionObserverMapping(typeof(Observable))]
public static TResult Transform<T, TResult>(this T obj, Func<T, TResult> selector)
{
	return selector(obj);
}

I also have these two mapped methods in the Observable class.

 

public static IValueProvider<TResult> Transform<TSource, TResult>(TSource source, Func<TSource, TResult> selector)
{
	return ValueProvider.Static(selector(source));
}

public static IValueProvider<TResult> Transform<TSource, TResult>(TSource source, Func<TSource, IValueProvider<TResult>> selector)
{
	return ObservableGeneric<TSource, TResult>.Transform(source, selector);
}

 

If I delete the first mapped method, will Obtics figure out that it can use the ordinary method when there are no live parameters?  Or will it always use the second mapped method at that point?
If the first mapped method should not be deleted for performance reasons, is that a good way to write it?
Thanks for your help understanding this.
Mar 20, 2011 at 3:26 AM

Okay, I found my own answer to the first question.  It always uses the second mapped method if the first is missing.

The second question is still relevant.

Also, I now have a third question.  Will the second mapped method do the same thing as the first mapped method when there are no live parameters and the chain is built using the ExpressionObserver?

Is there some way to contribute this sort of info to the docs?  I wouldn't mind helping out that way.  No big deal though... the forum also acts as documentation.

Thanks!

Coordinator
Mar 21, 2011 at 7:19 PM

In case the expression observer can not rewrite the 'selector' expression to an observable expression (or only in a trivial way) then it will choose the first method. In any other case it will choose the second.

In case only the first method was provided it would never try to rewrite any part of the 'selector' expression that depends on its one and only (TSource) parameter. Therefore it is best to at least implement the second variation.

All the less reactive variations (like the first method) may be left out without loss of functionality though they may lead to a performance increase when they are implemented.

Wether the second method would do the same thing as the first naturally depends on the implementation. They should do the same thing (the second only more change aware).

Mar 21, 2011 at 8:10 PM

Thanks for your thoughts on this.  There was one question that remained unanswered.  If I implemented the second only, would Obtics internally produce something as performant as the first if it sees the selector expression doesn't require an IValueProvider?  In other words, does Obtics figure out that the IValueProvider isn't really needed and then just use something like ValueProvider.Static(value)?

Kind of a convoluted question. :(

Coordinator
Mar 24, 2011 at 10:19 AM

It will not be as performant as your first method. Obtics will call your second method with a trivialy rewritten 'selector' parameter ( Func<TSource,IValueProvider<TResult>> rewrittenSelector = s => ValueProvider.Static( selector(s) ) )

The second method will be heavier because it offers more functionality (is more change aware).

Obtics can not be more clever because it does not know what happens inside your Transform method. The method is already compiled into incomprehensable IL code.