I am trying to understand specifically why it is neccessary to have this Where<TSource>
What does the type straight after Where tell you?
I understand the 'this' concept which means its an extension method but cannoth understand the type after Where
public static IEnumerable<TSource> Where<TSource>(
this IEnumerable<TSource> source,
Func<TSource, bool> predicate
)
Func<TSource, bool> is a pointer to a function which takes TSource as parameter and returns boolean. For example if you had the following function:
public bool Foo(SomeType abc)
{
return abc.SomeProperty == "123";
}
you could pass it as argument to the Where method if you had a list of SomeType:
SomeType[] values = ...
var result = values.Where(Foo);
You could also use an anonymous function which avoids you the need to declare another function explicitly:
SomeType[] values = ...
var result = values.Where(x => x.SomeProperty == "123");
UPDATE:
I seem to have misunderstood the question. The type after the name of the function Where<TSource> indicates a generic function definition. It indicates that this function has a generic argument which can be of any type. So for example when you write:
SomeType[] values = ...
var result = values.Where(x => x.SomeProperty == "123");
TSource equals SomeType and the compiler is capable of automatically inferring it from the delegate. You could specify it explicitly but it's too much of a writing:
SomeType[] values = ...
IEnumerable<SomeType> result = values.Where<SomeType>(x => x.SomeProperty == "123");
The type in <...> after Where is a declaration of generic type parameter. The Where method is generic which means that some of the types involved in its type declaration can be provided when the method is used. In C#, this is called generics.
The <...> is a place where you declare types that the caller needs to specify when using your method. It is, in some way, similar to declarations of parameters
When using parameters, you say that the caller needs to give you some values and you give them names (e.g. source and predicate).
When writing generic method, you say that the caller needs to give you some type and you give the type a name (e.g. TSource) that you can use in the method declaration and body.
A simple answer to your question would be for type safety and IntelliSense while programming. (All the benifits that Generics provide).
LINQ to Objects works on Extension Methods defined in a type named Enumerable. Mostly, they deal with type IEnumerable<T>.
So, for example, when you want it to operate on a List<String>, the Where<TSource> becomes Where<String>. And C# 3.0 type inferance comes into picture so that you dont have to explicitly specify the String part. Since, the compiler knows you are working with IEnumerable<T>.
To sumarrize, when you use Where method on a List, the method expects an IEnumerable<String> and a Predicate that takes String to filter on input sequence as an input and provides with an IEnumerable<String> as an output.
Related
So, I ran across an answer by Servy ( https://stackoverflow.com/a/15098242/496680 ) and some of his code does this:
public static int BinarySearch<TSource, TKey>(...)
for an extension method, but he calls it like this:
arr.BinarySearch(...)
I asked around and somebody metioned that its an implied generic type parameter.
I googled them but found no information on them.
I understand how generics work but I'm failing to understand how/when to use these.
Why does servy use them in his extention method?
Is there a more official name for these that I can search for?
Well, you left out the most important part that makes it all work. The type parameters can be inferred by the actual object parameters passed in.
For instance:
static class Extensions {
internal static IEnumerable<U> Test<T, U>(
this IEnumerable<T> items,
Func<T, U> converter) {
foreach (T item in items) {
yield return converter(item);
}
}
}
This extension method works on any IEnumerable class and will convert each item in the enumeration to another type based on the converter you provided. This is standard generics.
Now, there are many ways to call this method:
IEnumerable<int> values = Enumerable.Range<int>(1, 10);
Func<int, string> converter = i => i.ToString("0.00");
// Variation 1, explicit calling
IEnumerable<string> results1 = Extensions.Test<int, string>(values, converter);
// Variation 2, explicit calling with type inference
IEnumerable<string> results2 = Extensions.Test(values, converter);
// Variation 3, extension method calling, still providing explicit types
IEnumerable<string> results3 = values.Test<int, string>(converter);
// Variation 4, extension method with type inference
IEnumerable<string> results4 = values.Test(converter);
All four variations call the same method and return the same result. Type inference works by looking at the parameters passed and automatically inferring their types based on what's being provided. In our examples above, it's able to determine that type T is of type int because we passed in an IEnumerable<int> into the parameter for IEnumerable<T>. It is also able to infer that type U is of type string because we passed in a Func matching the initial type of T with int and returning a string. So the Func<T, U> is filled in with our converter function of Func<int, string>.
From the inference above, it's a standard generic method at that point. Type inference and extension methods are nothing more than convenience/syntactic sugar. In fact, if you decompile the output you can see that extension methods are replaced with static calls and are usually defined with the type parameters explicitly filled out. (This varies based on your decompiler and the set options).
He uses a generic method in this case because it allows his method to work with any type contained within a Collection<T>. The generic method makes this very flexible, and usable for any type. He uses the type inferrence when calling the method because it simplifies the code at the call site.
The automatic handling is called Type Inferrence, and is covered, in detail, in the C# Language Specification, section 7.5.2: Type Inferrence. If you want to understand it in detail, I would recommend downloading the C# language specification.
The term I usually hear is 'type inference'.
I have a class with an overloaded Format method.
class FormatStuff
{
public static string Format(object arg)
=> HandleObjectStuff();
public static string Format(IEnumerable<object> args)
=> HandleListStuff();
}
Now, when I call
FormatStuff.Format(null);
I end up in the second overload with the IEnumerable parameter.
But in my case, I call the method from within a function like this:
public static string DoStuff(IEnumerable<int> intnumerable)
{
StringBuilder sb = new StringBuilder();
sb.Append(FormatStuff.Format(intnumerable));
return sb.ToString();
}
When I call this function like
DoStuff(null);
I end up in the first overload with the single object parameter, even though in both cases null is passed as the parameter.
Why is this and what can I do to end up in the second overload that matches the type of the DoStuff-parameter?
Edit:
The question has been marked as a possible duplicate of this one. I don't think that's entirely the case, because the salient point that helped me understand my problem was, that an IEnumerable<int> is not an IEnumerable<object>.
In general that means, that one cannot expect an IEnumerable of any type to be an IEnumerable of object, which I did not know.
This conclusion is not drawn in the mentioned post.
Which overload to call (binding) is statically fixed for each invocation expression at compile-time (unless you use type dynamic at compile-time). Just because the expression you use for argument happens to evaluate to another type when the program runs, the overload will not magically change.
Examples:
FormatStuff.Format(null);
The compile-time type does not exist (null), but since there is an implicit conversion from the null literal to object and an implicit conversion from null to IEnumerable<object> as well, both overloads are candidates. In that case the overload with IEnumerable<object> is preferred because it is more specific.
FormatStuff.Format((object)null);
In this case the compile-time type of the expression is object, so only one overload applies, and that is used.
IEnumerable<int> intnumerable
// ...
FormatStuff.Format(intnumerable);
In the above case the compile-time type of what you pass is IEnumerable<int>. Here int is a value-type. An IEnumerable<int> is not an IEnumerable<object> at compile-time. This is fixed at compile-time; it does not matter whether intnumerable happens to be null at run-time, and if non-null, it does not matter what the actual type (some concrete class or struct implementing IEnumerable<int>) is at run-time.
IEnumerable<string> strEnumerable
// ...
FormatStuff.Format(strEnumerable);
Finally, in this case, since string is a reference type, the compile-time covariance of IEnumerable<out T> applies. So an IEnumerable<string> is an IEnumerable<object>. Therefore both overloads apply, and the most specific one is preferred.
To achieve what you want, your method must be able to distinguish between the two method calls.
When you pass null the Format() method doesn't know if your null is an object or IEnumerable<object> since both are of type object.
To solve your issue you can do one of the following:
1 Change the second method as Format(IEnumerable<int> args)
OR
2 Change the type signature of your method by adding optional arguments. Take this as an example
I'm a beginner in C#. I encountered below code snippet in my project. I do not understand how ViewHelper.IsInView has been called without passing any parameters. Could anyone explain me this. Thanks in advance.
public static class ViewHelper
{
public static bool IsInView(IFrameworkElement element)
{
----------
}
}
var Result = Views.Any(ViewHelper.IsInView);
The Any method accepts a delegate - a pointer to a function - of the form Func<T, bool>. Meaning it expects a method that accepts an element of the type of the collection (I'm guessing IFrameworkElement in your case) and returns a bool - which is exactly the signature of the IsInView method.
The Any method then executes this delegate on elements in the Views collection until it encounters one that returns true.
In C#, there is an implicit conversion from a "method group" to a delegate type. Essentially, when you write
Views.Any(ViewHelper.IsInView)
It translates into
Views.Any(new Func<IFrameworkElement, bool>(ViewHelper.IsInView))
What is being passed to Enumerable.Any is a delegate, the method is not being called at this point. If there are any views then Any will call that delegate with one or more of the views as the argument.
The delegate you're passing to Any has been created through something known as implicit method group conversion.
Views.Any is expecting a delegate of the type Func<IFrameworkElement, bool>, meaning it takes a single parameter of type IFrameworkElement and returns bool. You can create such a delegate from your method, as the signatures are compatible. This is how you would explicitly do this:
Func<IFrameworkElement, bool> predicate =
new Func<IFrameworkElement, bool>(ViewHelper.IsInView);
However, from C# 2.0 such a conversion can be done implicitly, meaning this code is exactly the same:
Func<IFrameworkElement, bool> predicate = ViewHelper.IsInView;
I am trying to build OrderBy expression the problem is when I pass var object to TSource the Type for TSource will be object not the Actual Column type
for example the Actual type is int but TSource type is object.
Type tblType = tblObj.GetType();
PropertyInfo propinfo;
propinfo = tblType.GetProperty(ColumnName);
if (propinfo == null)
{
return null;
}
var instance = Activator.CreateInstance(propinfo.PropertyType);
result = result.OrderBy(GetOrder(item.ColumnName, tblObj, instance));
and here is the lambda expression builder
public Expression<Func<T, TSource>> GetOrder<T,TSource>(string field, T item,TSource source)
{
if (string.IsNullOrEmpty(field))
{
return null;
}
var param = Expression.Parameter(typeof(T), "c");
Expression conversion = Expression.Convert(Expression.Property
(param, field), typeof(TSource));
return Expression.Lambda<Func<T, TSource>>(conversion, param);
}
When not sure of the type, you can use dynamic so the type will be found at runtime level.
result = Enumerable.OrderBy(
result,
GetOrder(item.ColumnName, tblObj, (dynamic)instance));
You either must use dynamic keyword or use reflection.
But, you can solve your probelm with dynamic more easily.
The only problem is that, extension methods will not be dynamically dispatched.
So, you must call extension method as simple static method:
result = Enumerable.OrderBy(
result,
GetOrder(item.ColumnName, tblObj, instance as dynamic));
Also, you can ask a question "Why extension methods can not be dynamically dispatched?"
The asnwer by #EricLippert:
That means that in order to get a dynamic extension method invocation
resolved correctly, somehow the DLR has to know at runtime what all
the namespace nestings and "using" directives were in your source
code. We do not have a mechanism handy for encoding all that
information into the call site. We considered inventing such a
mechanism, but decided that it was too high cost and produced too much
schedule risk to be worth it.
So, CLR must find the namespace which holds extension method. CLR searches this and it it finds the method namespace, then it just changes for example, result.OrderBy to Enumerable.OrderBy(result, ...). But, in case of dynamic keyword, DLR(Dynamic Language Runtime) must find the class of this method in runtime, again based on included namespaces. Microsoft team rightly thinks that it is too high cost and avoids to implement it.
Method Activator.CreateInstance(Type type) returns object, not int.
May be you should unbox it to int before use;
Follow the documentation Activator.CreateInstance return object, so you have to cast it to destination type or you can use dynamic type, but than compiler can't check types.
So, I ran across an answer by Servy ( https://stackoverflow.com/a/15098242/496680 ) and some of his code does this:
public static int BinarySearch<TSource, TKey>(...)
for an extension method, but he calls it like this:
arr.BinarySearch(...)
I asked around and somebody metioned that its an implied generic type parameter.
I googled them but found no information on them.
I understand how generics work but I'm failing to understand how/when to use these.
Why does servy use them in his extention method?
Is there a more official name for these that I can search for?
Well, you left out the most important part that makes it all work. The type parameters can be inferred by the actual object parameters passed in.
For instance:
static class Extensions {
internal static IEnumerable<U> Test<T, U>(
this IEnumerable<T> items,
Func<T, U> converter) {
foreach (T item in items) {
yield return converter(item);
}
}
}
This extension method works on any IEnumerable class and will convert each item in the enumeration to another type based on the converter you provided. This is standard generics.
Now, there are many ways to call this method:
IEnumerable<int> values = Enumerable.Range<int>(1, 10);
Func<int, string> converter = i => i.ToString("0.00");
// Variation 1, explicit calling
IEnumerable<string> results1 = Extensions.Test<int, string>(values, converter);
// Variation 2, explicit calling with type inference
IEnumerable<string> results2 = Extensions.Test(values, converter);
// Variation 3, extension method calling, still providing explicit types
IEnumerable<string> results3 = values.Test<int, string>(converter);
// Variation 4, extension method with type inference
IEnumerable<string> results4 = values.Test(converter);
All four variations call the same method and return the same result. Type inference works by looking at the parameters passed and automatically inferring their types based on what's being provided. In our examples above, it's able to determine that type T is of type int because we passed in an IEnumerable<int> into the parameter for IEnumerable<T>. It is also able to infer that type U is of type string because we passed in a Func matching the initial type of T with int and returning a string. So the Func<T, U> is filled in with our converter function of Func<int, string>.
From the inference above, it's a standard generic method at that point. Type inference and extension methods are nothing more than convenience/syntactic sugar. In fact, if you decompile the output you can see that extension methods are replaced with static calls and are usually defined with the type parameters explicitly filled out. (This varies based on your decompiler and the set options).
He uses a generic method in this case because it allows his method to work with any type contained within a Collection<T>. The generic method makes this very flexible, and usable for any type. He uses the type inferrence when calling the method because it simplifies the code at the call site.
The automatic handling is called Type Inferrence, and is covered, in detail, in the C# Language Specification, section 7.5.2: Type Inferrence. If you want to understand it in detail, I would recommend downloading the C# language specification.
The term I usually hear is 'type inference'.