lapucca
asked on
How can I learn to understand this crazy syntax? Enumerable.OrderBy<TSource, TKey> Method (IEnumerable<TSource>, Func<TSource, TKey>)
Hi,
I'm looking at this https://msdn.microsoft.com/en-us/library/bb534966(v=vs.110).aspx
The syntax and how it translates to coding is baffling for me. Is this Linq sytanx? Any suggestion that I can understand what it mean with
Enumerable.OrderBy<TSource
Thank you.
I'm looking at this https://msdn.microsoft.com/en-us/library/bb534966(v=vs.110).aspx
The syntax and how it translates to coding is baffling for me. Is this Linq sytanx? Any suggestion that I can understand what it mean with
Enumerable.OrderBy<TSource
Thank you.
Paul MacDonald
You can't, which is why Microsoft pushes it so hard. Stick with VB.Net like the rest of us. C# has no advantage.
ASKER
Lol... Too late for that advice for me. I'm a C# developer but haven't done so for about 4 years and now having problem understanding these new syntax.
FWIW, you've picked one of the more convoluted examples.
C# has always seemed backwards to me, and every time we consider converting from VB we look at some of the really difficult stuff we've done and decided we would never pull it off in C#.
C# has always seemed backwards to me, and every time we consider converting from VB we look at some of the really difficult stuff we've done and decided we would never pull it off in C#.
Also note that this is for lambda expression, and it's a lot easier if you see them in practice.
Take some
List<Class> myList;
myList.OrderBy( c => c.FirstProperty).ThenBy( c=> c.SecondProperty);
One advantage to C# . . . it does make use of int Pointers which VB has still not yet done. They're 99.9% the same - and you never need it until that one esoteric situation when you realized you're really boned without it. I've taken it upon myself to keep in touch with both languages, this way I can work for a job that uses either.
Take some
List<Class> myList;
myList.OrderBy( c => c.FirstProperty).ThenBy( c=> c.SecondProperty);
One advantage to C# . . . it does make use of int Pointers which VB has still not yet done. They're 99.9% the same - and you never need it until that one esoteric situation when you realized you're really boned without it. I've taken it upon myself to keep in touch with both languages, this way I can work for a job that uses either.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
P.S.
FWIW, I find VB.NET's lambda syntax to be much more of a pain in the butt than C#'s.
e.g.
It's even worse when you get into multi-line lambdas ; )
FWIW, I find VB.NET's lambda syntax to be much more of a pain in the butt than C#'s.
e.g.
Dim byFirstName = listOfPeople.OrderBy(Funct
It's even worse when you get into multi-line lambdas ; )
ASKER
Kyle,
I get myList.OrderBy( c => c.FirstProperty).ThenBy( c=> c.SecondProperty); and the example at the link. My problem is I just don't know how to intrepret that syntax they provided and convert that to code.
public static IOrderedEnumerable<TSource
this IEnumerable<TSource> source,
Func<TSource, TKey> keySelector
)
Thank you
I get myList.OrderBy( c => c.FirstProperty).ThenBy( c=> c.SecondProperty); and the example at the link. My problem is I just don't know how to intrepret that syntax they provided and convert that to code.
public static IOrderedEnumerable<TSource
this IEnumerable<TSource> source,
Func<TSource, TKey> keySelector
)
Thank you
P.P.S.
The convention that MS uses for Func and its overloads is that the last type parameter (the thing(s) inside the angle brackets) is the return type, and everything else is the type of a parameter, in left-to-right-order. So a Func<string> should wrap a method that takes no parameters and returns a string; a Func<string, int> should wrap a method that has one parameter or type string and which returns an int; a Func<byte, string, char> should wrap a method that has two parameters, the first being type byte, the second being type string, and which returns a char; etc.
The convention that MS uses for Func and its overloads is that the last type parameter (the thing(s) inside the angle brackets) is the return type, and everything else is the type of a parameter, in left-to-right-order. So a Func<string> should wrap a method that takes no parameters and returns a string; a Func<string, int> should wrap a method that has one parameter or type string and which returns an int; a Func<byte, string, char> should wrap a method that has two parameters, the first being type byte, the second being type string, and which returns a char; etc.
ASKER
Kaufmed,
LOL... I'm glad you're taking side with C#. Thank you for the wonderful explanation. I'm still digesting all of it.
LOL... I'm glad you're taking side with C#. Thank you for the wonderful explanation. I'm still digesting all of it.
Kaufmed elegant explanation.