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;
Related
Forgive me if this is a stupid question but I am not sure where to look. I have this code that compiles fine:
static int Main(string[] args)
{
var parserResult = CommandLine.Parser.Default.ParseArguments<Options>(args);
parserResult.WithParsed<Options>(options => OnSuccessfulParse(options));
parserResult.WithNotParsed<Options>(errs =>
{
var helpText = HelpText.AutoBuild(parserResult, h =>
{
return HelpText.DefaultParsingErrorsHandler(parserResult, h);
}, e =>
{
return e;
});
Console.WriteLine(helpText);
ReturnErrorCode = ErrorCode.CommandLineArguments;
});
return (int)ReturnErrorCode;
}
My query has to do with this line of code:
parserResult.WithParsed<Options>(options => OnSuccessfulParse(options));
I understand that with a Lambda Expression the value on the left of the => is the value and value on the right is the expression.
What exactly is options? Why does it compile? It works absolutely fine. But what is it?
I don't know if this helps:
I might be barking up the wrong tree with my understanding of this. I admit I am struggling with the concept. Any explanation appreciated.
I see several questions but I can't explain it in my situation.
Update
OnSuccessfulParse declaration is:
private static void OnSuccessfulParse(Options options)
The WithParsed code is provided here
Lambda expression is the delegate of type Action<Options>. It is a callback from the parser into your code to inform you that the parse has been successful, and pass you Options object obtained as the result of the parse.
As far as options goes, it's just a name that you picked for the parameter to be passed into OnSuccessfulParse method. It is completely unnecessary here - this method group equivalent call will compile and run just the same:
parserResult.WithParsed<Options>(OnSuccessfulParse);
Here is the definition of WithParsed<T> method from github project:
public static ParserResult<T> WithParsed<T>(this ParserResult<T> result, Action<T> action)
{
var parsed = result as Parsed<T>;
if (parsed != null) {
action(parsed.Value);
}
return result;
}
This method is rather straightforward: it takes parse result, tries casting it to a successful parse, and if the cast is valid, calls a delegate that you supply. The WithNotParsed<T> method casts to unsuccessful NotParsed<T> result, and makes a call if the cast is valid.
That's a C# (.Net) way of representing function blocks.
Essentially an Action<Type> is an invocable type that roughly means pass an instance of Type in and execute the block.
E.g. we can write
public void Do(){
this.CallStuff(s => Console.WriteLine(s)); // or you can use a method group and do this.CallStuff(Console.WriteLine);
}
public void CallStuff(Action<string> action){
var #string = "fancy!";
action(#string);
}
In this case the s type is string.
In your example there is a type called Options defined somewhere and it is passed into an action.
Additionally, if you look at decompiled code, anonymous method blocks passed to actions are compiled as static anonymous types inside your class (because c# does not support dynamic code blocks, like, for example, obj-c does).
Another thing to look into are Func<out type> -> these are essentially the same as Action<> except the LAST type in the generic definition is the type they return.
UPD
#elgonzo raises a good point - Action<> and Func<> are actually just delegates; meaning that you can define a real method and pass it along as an Action or Func and then no anonymous static class will be compiled.
However in practice you will see that a lot of code defines those inline, and then the in-line code block needs to reside within a method somewhere, so the compiler puts it into the statis anonymous class.
What exactly is options?
options is i/p parameter to delegate represented by lambda expression
Why does it compile?
Simply because it adheres all syntactical and semantic rules of compiler ;) Like (x)=>x+1 is lambda expression to represent Func<int,int> (there can be another delegate to match same signature as well)
If your method expects Func<int,int> as parameter and argument passed is (x)=>x+1 then compiler infers this as x of type int. Compiled IL code would be equivalent to passing instance of delegate as an argument to method. Like :
call((x)=>x+1) will be compiled to call(new Func<int,int>(myMethod)) where call method definition is :
void Call(Func<int,int> someparam) {}
But what is it?
I think above response should have addressed this query.
I've used short.Parse(somestring) in the past. But recently I've seen a confusing usage of short.Parse() like below:
var shortArray = Array.ConvertAll(stringArr, short.Parse);
So, Array.ConvertAll expects an array and a converter. Well, fine! But how are we passing the short.Parse as (or like) a property? I don't find such a property in Int16 struct. So, what is happening here actually?
Array.ConvertAll takes an instance of a Converter<TIn, TOut> delegate as its second parameter. The signature of this delegate is substantially the same as short.Parse - both return a value for a single argument.
The compiler will convert a 'method group' to a compatible delegate. This is known as implicit method group conversion.
For comparison, the explicit creation of the delegate would look like this:
Array.ConvertAll(stringArr, new Converter<string, short>(short.Parse));
So, to answer you question: it's still a method, not a property. What you are doing here is passing the method as a delegate. You are providing ConvertAll with a function to call: when it converts an element in the source array, it will execute short.Parse(element) and use the value returned in the new array.
short.Parse is a method. But it is possible to pass a method as an argument.
Note the difference between calling a method and passing the value returned by that method (short.Parse()), and passing the method itself (short.Parse).
Internally, this would be passing the address of the method so that the receiver of that argument can call it.
What's it called when a method that takes a lambda expression as the parameter, such as Enumerable.Where, is invoked without actually declaring a variable or method parameter in the expression?
For example, I'm familiar with this lambda expression syntax:
public string GetDigits(string input)
{
return new String(input.Where(i => Char.IsDigit(i)).ToArray());
}
However, I was surprised to find out that this can also be written as:
public string GetDigits(string input)
{
return new String(input.Where(Char.IsDigit).ToArray());
}
What's going on in that second snippet, where the Char.IsDigit() method is (apparently) being called with an implicit parameter? What is this syntax called?
Methods don't accept lambdas as parameters. They accept delegates as parameters. A lambda is just one way of creating a delegate.
Another way is supplying a method group, as is done in your second example, which can be converted to a delegate.
A similar way is to use the anonymous method feature. This was more or less replaced with lambdas when they were added though, so you don't see it much. Your example using that syntax would be:
Func<char, bool> predicate = delegate(char c) { return Char.IsDigit(c); };
Yet another way would be to create a delegate using Delegate.CreateDelegate. (This isn't something you see all that often though.)
A final way is to have a delegate variable that you got from somewhere else. (That somewhere else would have created the delegate using one of these other options.)
What's going on in that second snippet, where the Char.IsDigit() method is (apparently) being called with an implicit parameter? What is this syntax called?
It's not being called. That's the whole point. We're trying to create a delegate. A delegate is an object that keeps track of a method to be invoked, and an object that it should be invoked on. You can then invoke the delegate and it will call the method that was used to create it. So here you're not calling IsDigit, you're creating a delegate that is pointing to the IsDigit method, and that will call it whenever that delegate is invoked.
When you use a lambda you're creating a new method, possibly in a new class, (neither of which have a name you can refer to, but they'll have one at runtime) and the body of that anonymous method will call IsDigit. The lambda then resolves to a delegate pointing to that anonymous method, which maintains the semantics of the other example of having a method that when called, calls an anonymous method which, in its implementation, calls IsDigit. It's adding an extra layer of indirection (that may or may not just get optimized out at runtime) to accomplish the same thing.
The signature of Enumerable.Where is:
public static IEnumerable<TSource> Where<TSource>(
this IEnumerable<TSource> source,
Func<TSource, bool> predicate
)
This:
input.Where(i => Char.IsDigit(i))
is equivalent to writing:
Func<char, bool> temp = i => Char.IsDigit(i);
input.Where(temp);
so it creates an anonymous function with a parameter i that calls Char.IsDigit.
This:
input.Where(Char.IsDigit)
is equivalent to
Func<char, bool> temp = Char.IsDigit;
input.Where(temp);
that is equivalent to:
Func<char, bool> temp = new Func<char, bool>(Char.IsDigit);
input.Where(temp);
so it creates a delegate to Char.IsDigit and then passes it to input.Where.
So the second one removes the "man-in-the-middle" (the anonymous function). In this particular case it is "legal" because the i parameter of the anonymous function is passed "as is" to Char.IsDigit. It would have been different if it was:
input.Where(i => !Char.IsDigit(i))
in this case, you can't remove the man-in-the-middle (the anonymous function).
There is no name for all of this (or you could call the first "creating and passing a delegate to an anonymous function" and the second "creating and passing a delegate created from a method group"... but they aren't beautiful catchphrases, they are more a description of what you are doing)
Because the compiler will implicitly cast the method group to a delegate if it finds a single method that matches the expected signature, in this case a delegate taking a single char as input and returning a bool.
Your Where expects a Func<char, bool>, which is a delegate for methods that take a char argument and return a bool. Anything that matches this delegate is a valid argument for this Where.
The lambda you wrote initially matches this delegate by type inference: the compiler expects that i is char, based on the generic parameter of the enumerable source - and infers the return type as bool, because that's what the method call expression inside the lambda would return.
The Char.IsDigit method itself also matches this. Thus, referencing the method is another valid way of expressing the same thing. This is called a method group.
The semantic equivalence of these two possible arguments for Where also makes sense if you consider that for every lambda expression, the compiler generates an anonymous method and then passes that anonymous method where the delegate was expected.
To illustrate this, consider your original snippet:
Where(i => Char.IsDigit(i))
The above gets lowered by the compiler to:
bool AnAnonymousMethod(char i)
{
return Char.IsDigit(i);
}
and then:
Where(AnAnonymousMethod)
As you can see, the lambda syntax (in cases where you don't have captured variables, like here) is just syntactic sugar for writing an anonymous method and then using the method group of this newly written method as the argument wherever a compatible delegate is expected.
Delegates, yes I am trying to understand the use of this concept, what problems it helps to solve in C#. So far, I really like the Decoupling facility it provides code with. Then I came across Predicate Delegates. According to this MSDN library article it shows they are, delegates that takes any data type paramter and returns a bool type value....
It also says, this particular delegate takes generics, <T>, can it be said then any Type...
So is it correct to say Predicate Delegate is simply a Boolean Delegate? That means any Delegate with Boolean Return Type? Or is there more to it for specifying with a different name: Predicate Delegates..?
E.g.
delegate bool BooleanDelegate(anytype parameter);
BooleanDelegate bd = new BooleanDelegate(yesno);
//assuming parameter type is int
MessageBox.Show(bd.Invoke(2).ToString());
public bool yesno(anytype parameter)
{
If (parameter == 2)
{
return true;
}
Else
{
return false;
}
}
In general, a predicate is a boolean-valued function. So yes, any function that returns a boolean is a predicate.
Yes, a Predicate<T> represents a method which take in one parameter of type T, and returns bool. For example, a Predicate<string> represents a method that takes in a string and returns a bool.
For example:
Predicate<string> p = String.IsNullOrEmpty; // this static method has the correct signature and return type
with which you can say
bool answer = p("your words");
The generics means that T can have a different meaning in different situations. So you don't have to make a whole bunch of delegate types like StringPredicate, DateTimePredicate, BicyclePredicate, and so on, but you can use Predicate<DateTime>, Predicate<Bicycle>, ...
A Predicate<T> has the same signature and return type as a Func<T, bool> (introduced in .NET version 3.5). Both are contravariant in T.
You:
So is it correct to say Predicate Delegate is simply a Boolean Delegate?
Its signature has to be correct. There must be exactly one parameter (not zero, or two or more). The parameter must not be ref or out. The parameter must have the correct type T (but the meaning of T can differ). For example a method that takes in a Bicycle could be a Predicate<Bicycle>, but not a Predicate<DateTime>.
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.