Now with most of the Linq methods like Where or First, it's simple once you understand lamdba expressions:

.SomeMethod(someField => someField.Property == value);

Now what about join?

So inner selector with an outer selector and a selector selects a selecting selector. Right got it.

Well let's try to break it down. First part is

this IEnumerable<TOuter>

So being that this is an extension method meaning this is the collection you are using this method on.

IEnumerable<TInner> inner

So second field must be the list you want to join to. Ok so far.

Func<TOuter, TKey> outerKeySelector

Now this is where it gets a little odd looking. We know we have Outer and Inner lists so there needs to be a way to join on something. Say Outer is User and Inner is UserAddress. Most likely you will have a UserID on both lists. If not, you do now. So basically what this part of the method is saying is "Give me the stupid key on the Outer (User) list that I should care about."

, user => user.UserID,

Next part:

Func<TInner, TKey> innerKeySelector

Pretty much the same thing, except now it needs the key from the Innerlist (UserAddress):

, address => address.UserID,

Now for the fun part:

Func<TOuter, TInner, TResult> resultSelector

Sa...say what? Ok this may look weird at first but you'll hate yourself for not seeing it. It's just asking you what to select from the two lists as some kind of hybrid object. See, you have to remember that with these linq methods, each method will produce a list. You can't just chain them together and have it remember every list you've made:

   user.Where(user => user.UserID > 1) // gives me a list of users
         .Select(user => new { user.UserName, user.UserAddress, user.UserID } 
         //Gives me new items with user name, address, and user id

From this simple method chain, the end list is NOT the same as the one you started with or the one produced by the where method.

The last part of the Join method needs you to tell it what it's going to produce from this join. Now it probably could just guess and include both lists, but that could be seen as sloppy and ultimately this gives you the choice of what exactly needs to be taken after the join. So:

, (user, address) => new { user, address});

So in this case, the newly created and joined list with be a list of items that have a user and address attached to it much like if you had a list of:

class UserAddressHybrid()
{
    public User user { get; set; }
    public UserAddress userAddress { get; set; }
}

So in other words, WHAT DO YOU WANT YOUR RESULTS TO LOOK LIKE?

In full it would look something like:

user.Join(address => address.User.UserID,  //IEnumerable<TInner> inner
             user => user.UserID,  //Func<TOuter, TKey> outerKeySelector
             address => address.UserID,  //Func<TInner, TKey> innerKeySelector
             (user, address) => new { user, address});  //Func<TOuter, TInner, TResult> resultSelector

Not so hard anymore, is it? You can start kicking yourself now.

• Linq Extension Methods Versus Linq Query Language… DEATHMATCH
• Cannot Resolve Method, Can’t Infer Return Type, and Funcs
• Uhg It Won’t End
• What Is Readable Addon

    Func<User, String> userName = user => user.UserName;
    Func<User, Boolean> userIDOverTen = user => user.UserID < 10;
    Func<User, Boolean> userIDUnderTen = user => user.UserID > 10;

As you can see the first one replaces the lamdba expression to get the user name, the second replaces a lamdba expression used to check if the ID is lower than 10, and let's face it, the third should be pretty easy to understand now.

NOTE: This is a silly example but it works.

    var userList =
      from user in userList
      where userIDOverTen(user)
      select userName;
Versus

    var otherList =
      userList
      .Where(IDIsBelowNumber)
      .Select(userName)

In this example, the second is a little less verbose since the extension method can make full use of the Func, but he Linq expression can't since it is look just for a Boolean rather than a Func that returns boolean. However, this is where it might be better to use the expression language. Say you already had a method that takes in more than just a user:

    private Boolean IDIsBelowNumber(User user, Int32 someNumber, Boolean doSomething)
    {
      return user.UserID < someNumber;
    }

Note: doSomething is just there because of the where extension method being ok with a method that takes in a user and integer and returns boolean. Kind of annoying for this example.

Now if you look at the Linq query:

    var completeList =
      from user in userList
      where userIDOverTen(user, 10)
      select userName;

You're good for it. Now the Extension Method:

    var otherList =
      userList
      .Where(IDIsBelowNumber????)
      .Select(userName)

Without a lambda expression, I really can't call that method. So now what I have to do is create a method that creates a Func based off the original method call.

    private Func<User, Boolean> IDIsBelowNumberFunc(Int32 number)
    {
      return user => IDIsBelowNumber(user, number, true);
    }

And then plug it in:

    var otherList =
      userList
      .Where(IDIsBelowNumberFunc(10))
      .Select(userName)

What does this all mean? You just lost 5 minutes of your life. I hope it was worth it.

• What Is Readable
• Uhg It Won’t End
• What Is Readable Addon
• Cannot Resolve Method, Can’t Infer Return Type, and Funcs

Say you want to order a list of objects by a number. Seems simple. Now if you have been paying attention you would know I like using Funcs.

  Func<SomeClass, Int32> orderByNumber =
    currentClass =>  currentClass.SomeNumber;

  anotherCollection = someCollection.OrderBy(orderByNumber);

Seems simple, but what if you wanted to use a method already defined in the class?

  private Int32 ReturnNumber(SomeClass currentClass)
  {
    return currentClass.SomeNumber;
  }

It seems like this could be the way to go, right?

  someCollection.OrderBy(ReturnNumber);

Compile and BOOOOOOM you get an error. It says it can't infer the return type of the method. Wait what? It's pretty obvious right, it's an integer. It had no problem inferring from the Func and you have to figure that the method itself is "typed" also. Well here's the problem (And you're dumb for not knowing this, but I'm not because I'm immune to dumb), ReturnNumber isn't a method, it's part of a method group. You can have a million (well maybe not that many) methods named ReturnNumber, all with different parameters. Why is this a problem? Well let's use lambda expressions:

  someCollection.OrderBy(currentClass =>  currentClass.SomeNumber);

At this point it knows two things: currentClass is a SomeClass and there is a Method that takes in a SomeClass and returns something. So with that in mind, it looks for such a method and finds the return type. This is no different with the Func since the Func is basically unique due to it being a named field. After all you can't have two fields named orderByNumber, but you can have many methods named ReturnNumber. That is where the problem is. When you use the second example:

  someCollection.OrderBy(ReturnNumber);

It can infer the SomeClass from the list and it sees the method. For there it has to find the method's return type. Wait, which method? If i Have 10 overloads, each with different return types, how does it know what type to use? Well the answers is, it doesn't. So basically you're screwed. Sucks, huh?

Side note: This works

  Func<SomeClass, Int32> orderByNumber = ReturnNumber;

• Linq Extension Methods Versus Linq Query Language… DEATHMATCH
• Uhg It Won’t End
• What Is Readable Addon
• What Is Readable

  someDictionary.Add("Hi", (Boolean doThis) => SomeMethod(doThis));

Can be done this way:

  someDictionary.Add("Hi", SomeMethod);

Where the dictionary is:

  Dictionary<String, Action<Bool>> someDictionary;
  someDictionary = new Dictionary<String, Action<Bool>>();

And SomeMethod is:

void SomeMethod(Boolean doSomething)
{
  //Something is to be done!
}

Which as far as I know, removes a step from the whole process. What does that mean? Well if you break the first one down into an anonymous method, it would look like this:

  someDictionary.Add("Hi", delegate(Boolean doThis){ SomeMethod(doThis); });

I am assuming this would create a reference to a completely new method as opposed to the second example which just uses the already existing method's reference. Fun yah?

• The Switch Remover: Convert Switch Statements to Dictionaries
• And some days I love programming
• I likz demz linq
• IEnumerable Extention Methods and Action

  switch(someDropDownList.SelectedValue)
  {
     case "hi":
        CallThisMethod();
        CallThatMethod();
        CallAnotherMethod();
        break;
     case "there":
        CallThisMethod();
        CallThatMethod();
        CallAnotherMethod();
        CallSomethingElse();
        break;
  }

And I'll give you this:

  doSomething[someDropDownList.SelectedValue]();

I bet you're ready to pay $19.95, but wait there's more. I'll actually throw in how I did such an amazing thing.

  Dictionary<String, Action> switchRemover = new Dictionary<String, Action>();
  switchRemover.Add("hi", () => RunHiMethod();
  switchRemover.Add("there", () => RunThereMethod();

Why that's amazing! But wait, I must be pulling something. What are these RunHiMethod and RunThereMethod methods? I must be pulling a fast one. Well, all they are is what the switch was doing before all wrapped up into one method. Don't get it?

  private void RunHiMethod()
  {
      CallThisMethod();
      CallThatMethod();
      CallAnotherMethod();
  }

But... but what if I had to pass something in? What would I do then??? Boy you got me there, I could tell you but I'd have to charge you more. Wait... I'll even throw that in for free. That's right. Remember that old mess we had?

  switch(someDropDownList.SelectedValue)
  {
     case "hi":
        CallThisMethod(someUser);
        CallThatMethod();
        CallAnotherMethod();
        break;
     case "there":
        CallThisMethod(someUser);
        CallThatMethod();
        CallAnotherMethod();
        CallSomethingElse();
        break;
}

Well shoot,we could do something like this:

  Dictionary<String, Action<User>> switchRemover = new Dictionary<String, Action>();
  switchRemover.Add("hi", currentUser => RunHiMethod(currentUser);
  switchRemover.Add("there", currentUser => RunThereMethod(currentUser );

And then:

  doSomething[someDropDownList.SelectedValue](currentUser);

That's amazing! You ready with your credit card? I knew you would be.

The Switch Remover does not come with a warranty.
The Switch Remover can not be used in all circumstances.
The Switch Remover assumes no fault for any physical conditions caused by the sudden surge of awesomeness you might feel.

SO BUY IT NOW!

• Linq Extension Methods Versus Linq Query Language… DEATHMATCH
• Uhg It Won’t End
• What Is Readable
• And some days I love programming

  foreach(Item current in itemList)
  {
     itemNameList.Add(current.Name);
  }

Versus

 var itemNameList = from item in itemList
                    select item.Name;

Or

  Func<Item, String> itemName = current => current.Name;
  itemNameList.Select(itemName);

So at this point it's really a matter of preference. Problem is, you have to look closer to why the third is so much more than syntax yummies.

Say you want a method that takes in a UserList and you want to select all the users that have a property (Could be name, address, whatever) that matches a string. Well you could do this:

 public IList<User> AllUsersThatMatch(IList<User> userList, NeededProperty property, String value)
 {
    IList<User> returnList;

    returnList = new List();

    foreach(UserItem currentUser in userList)
    {
        switch(property)
        {
            case(NeededProperty.Name):
                if(currentUser.Name == value)
                {
                    userList.Add(currentUser);
                }
                break;
            case(NeededProperty.Phone):
                if(currentUser.Phone == value)
                {
                    userList.Add(currentUser);
                }
                break;
        }
    }
 }

Or you could do this:

 public Func<User, Boolean> MatchesProperty(NeededProperty property, String value)
 {
    Func<User, Boolean> returnValue;

    switch(property)
    {
        case NeededProperty.Name:
            returnValue = currentItem => currentItem.Name == value;
            break;
        case NeededProperty.Phone:
            returnValue = currentItem => currentItem.Phone == value;
            break;
    }
    return returnValue;
  }

 public IList<User> AllUsersThatMatch(IList<User> userList, NeededProperty property, String value)
 {
    IList<User>  returnList;

    returnList = userList.Where(MatchesProperty(property, value));
    return returnList;
 }

Now which do you think is easier to upkeep? For those of you wondering what I did, I simply used a method that would return the Func I needed for the passed in Enum and called it in the Where clause. The amount of code is probably close to the same right now, but add in 5 more values for the NeededProperty enum and you'll see the code amount differing more and more.

I realize this isn't the best of example, and probably the first way could be refactored but the idea is still there. The Linq Method approach gives you a lot more flexibility in the long run with dynamic stuff like this.

• Linq Extension Methods Versus Linq Query Language… DEATHMATCH
• What Is Readable Addon
• What Is Readable
• And some days I love programming

var you = from factor in seansAwesomeness
          select new FactorLite
          {
             Amount = amount;
          };

or you could do:

Func<Person, FactorLite> selectFactorLite = currentFactor => new FactorLite { Amount = currentFactor.Amount };

seansAwesomeness.Select(selectFactorLite);

I guess it's a matter of preference, but the first seems way too verbose for something too simple.

• Linq Extension Methods Versus Linq Query Language… DEATHMATCH
• Uhg It Won’t End
• What Is Readable
• Cannot Resolve Method, Can’t Infer Return Type, and Funcs

Expression:

var result = from knowledge in Sean
             select knowledge.Linq;

As opposed to:

var result = Sean.Select(knowledge => knowledge.Linq);

Personally I would replace the lambda expression with a Func, but I can live with it right now. Anywho, the argument is that the first looks better than the second. I really don't see this as a looks problem, but a useage problem. Fact is, they both have their uses and you should know how to read both. Why is that? Well here's an example CAUSE I KNOW YOU WANT ONE!

One of my earlier posts had to do with solving the FizzBuzz thing with Linq where I gave you this bad ass solution:

 var result =
      listToConvert
      .Where(WhereBothDivisible(fizzNumber, buzzNumber))
      .Select(selectKeyValuePair("FizzBuzz"))
      .Concat(
            listToConvert
            .Where(WhereBuzzDivisable(fizzNumber, buzzNumber))
            .Select(selectKeyValuePair("Buzz")))
            .Concat(
                  listToConvert
                  .Where(WhereFizzDivisable(fizzNumber, buzzNumber))
                  .Select(selectKeyValuePair("Fizz")))
                  .Concat(
                         listToConvert
                        .Where(WhereNeitherDivisable(fizzNumber, buzzNumber))
                        .Select(selectKeyValuePair("Nothing")));

As you can see, I've used both Func fields and methods to return Funcs to clean up how this would look. I'll even show what it would look like without this approach:

var result = listToConvert.Where(currentItem =>
             IsDivisible(currentItem, fizzNumber) && IsDivisible(currentItem, buzzNumber)
             ).Select(currentItem => new KeyValuePair(currentItem, "FizzBuzz")).Concat(...

Now I can totally admit that this second one I am showing is just ouch. So the first lesson to be learn is that Funcs and Methods that return Funcs can significantly clean up the Linq Method approach.

Now you could do the same with expressions:

 var fizzBuzz = from currentNumber in listToConvert
                where WhereBuzzDivisable(fizzNumber, buzzNumber)
                select selectKeyValuePair("FizzBuzz");

 var buzz = from currentNumber in listToConvert
            where WhereBuzzDivisable(fizzNumber, buzzNumber)
            select selectKeyValuePair("Buzz");

 var fizz = from currentNumber in listToConvert
            where WhereFizzDivisable(fizzNumber, buzzNumber)
            select selectKeyValuePair("Fizz");

var neither = from currentNumber in listToConvert
              where WhereNeitherDivisable(fizzNumber, buzzNumber)
              select selectKeyValuePair("Fizz");

Ok so nice and pretty, but now what? Concatenation. This is where is gets ugly:

  fizzBuzz.Concat(fizz.Concat(buzz.Concat(neither))));

OR

 var fizzBuzz = from currentNumber in listToConvert
                where WhereBuzzDivisable(fizzNumber, buzzNumber)
                select selectKeyValuePair("FizzBuzz")
                .Concat(
                     from currentNumber in listToConvert
                     where WhereBuzzDivisable(fizzNumber, buzzNumber)
                     select selectKeyValuePair("Buzz"))
                     .Concat(....);

See what I'm getting at? The non expression one is looking a bit better now or maybe this is a fight to see which is less fugly. Now I admit that this may not be the best FizzBuzz solution, but it gives an example or where the Linq queries can go very wrong.

• Linq Extension Methods Versus Linq Query Language… DEATHMATCH
• Uhg It Won’t End
• What Is Readable Addon
• Solve FizzBuzz Using Linq Extension Methods

Next you have a list of processes that are currently running and you want to get all the processes that match the names in the BannedPrograms list AND if the current day is a banned day.

First you need the day checked function:

private static Func<DayOfWeek, Boolean> dayIsToday =
  currentDay => currentDay == DateTime.Now.DayOfWeek;

Then you need the method to get the banned processes that are currently running:

private static Process[] GetBannedProcesses(BannedProgram[] programs, Process[] processes)
{
  var processList = from process in processes
  where
  (
    from program in programs
    where program.DaysBanned.Any(dayIsToday)
    select program.ProcessName
  ).Contains(process.ProcessName)
  select process;

  return processList.ToArray();
}

What this is doing:

Well if you look at this:

from program in programs
where program.DaysBanned.Any(dayIsToday)
select program.ProcessName

This is going to grab any BannedProgram that has a DayOfWeek that matches today and it will select only it's name. This will give you a list of names of the BannedProcesses that can not be played today.

var processList = from process in processes
where
(
  from program in programs
  where program.DaysBanned.Any(dayIsToday)
  select program.ProcessName
).Contains(process.ProcessName)

This checks to see if any of the currently running processes have a name that matches a name in the banned program list.

And now you have a list of processes to kill. Yay. Not sure this is a big deal, just thought it was a fun example of using linq and subselects.

USING???

using System;
using System.Diagnostics;
using System.Linq;
using System.ServiceProcess;
using System.Windows.Forms;

• Linq Extension Methods Versus Linq Query Language… DEATHMATCH
• Uhg It Won’t End
• What Is Readable Addon
• What Is Readable

The idea is simple, take something like this:

currentItem => currentItem.BooleanMethodOne() && currentItem.BooleanMethodTwo()

but say you only want to have one clause or both. Well you could make three separate expressions, but what if you wanted to add even more later? What if you wanted to mix and match? What if you're reading thing because you watched to see what page could possibly be on the last page of a google search? Well I have answers... stolen answers.

First the needed And and Or methods:

public static Expression<Func<T, Boolean>> And<T>(
   Expression<Func<T, Boolean>> expressionOne,
    Expression<Func<T, Boolean>> expressionTwo
)
{
  //Basically this is like a bridge between the two expressions.  It will take the T
  //parameter from expressionOne and apply it to expression two. So if 
  // oneItem => oneItem.OneMethod() is expressionOne
  // twoItem => twoItem.TwoMethod() is expressionTwo
  //it would be like replacing the twoItem with the oneItem so that they now point
  //to the same thing.
  var invokedSecond = Expression.Invoke(expressionTwo, expressionOne.Parameters.Cast<Expression>());

  //Now this is to create the needed expresions to return.  It will take both early expressions
  //and use the item from the first expression in both.
                    
  //It will look something like this:
  //currentItem => (currentItem.OneMethod And Invoke(currentItem => currentItem.TwoMethod()))
  //As you can see, it looks to be running expressionOne and then a new method that basically
  //calls expressionTwo with the same value (currentItem)
  return Expression.Lambda<Func<T, Boolean>>(
   Expression.And(expressionOne.Body, invokedSecond), expressionOne.Parameters
  );
}

public static Expression<Func<T, Boolean>> Or<T>(
Expression<Func<T, Boolean>> expressionOne, 
Expression<Func<T, Boolean>> expressionTwo
)
{
  var invokedSecond = Expression.Invoke(expressionTwo, expressionOne.Parameters.Cast<Expression>());

  return Expression.Lambda<Func<T, Boolean>>(
   Expression.Or(expressionOne.Body, invokedSecond), expressionOne.Parameters
  );
}

And here's a test for it:

String[] list;

list = new String[] { "a", "b", "c", "ac", "ab", "cc", "d", "dd", "dc" };

Expression<Func<String, Boolean>> stringLikeA = currentString => currentString.Contains("a");
Expression<Func<String, Boolean>> stringLikeB = currentString => currentString.Contains("b");
Expression<Func<String, Boolean>> stringLikeC = currentString => currentString.Contains("c");

Expression<Func<String, Boolean>> neededUser = And<String>(stringLikeA, stringLikeB);
list.Where(neededUser.Compile());

//a
Assert.IsTrue(list.Where(neededUser.Compile()).Count() == 1);  //ab

//a, c, ac, ab, cc, dc
neededUser = Or<String>(stringLikeA, stringLikeC);

Assert.IsTrue(list.Where(neededUser.Compile()).Count() == 6);

//ab, c, ac, cc, dc
neededUser = And<String>(stringLikeA, stringLikeB);
neededUser = Or<String>(neededUser, stringLikeC);
Assert.IsTrue(list.Where(neededUser.Compile()).Count() == 5);

USINGS!!ONEONE

using System;
using System.Linq;
using System.Linq.Expressions;
using Microsoft.VisualStudio.TestTools.UnitTesting;

• Linq Extension Methods Versus Linq Query Language… DEATHMATCH
• Uhg It Won’t End
• What Is Readable Addon
• What Is Readable

  List<String> newList = userList.Select(user => user.Name);

Or

  List<Int32> newList = userList.Select(user => user.ID);

So either you get a list of Names or IDs. What the hell do you care? Well if you are capable of breathing, you should also notice that one list is a list of strings the other a list of integers. What if you wanted a generic select method? Well for starters you would do something like this:

public List<String> SelectFromUserList(Func<User, String> selectMethod, List<User> userList)
{
  return userList.Select(selectMethod).ToList();
}

Where the select method for a user name would be something like this:

  List<String> nameList = SelectFromUserList(currentUser => currentUser.UserName, userList);

Sweet... oh wait, that only works if I want a list strings. Great if I wanted LastName, FirstName, ect but sucks if I wanted an integer ID.

  List<String> nameList = SelectFromUserList(currentUser => currentUser.UserID, userList); //BOOM

But wait, you can do that!

public List<K> SelectUserNameList<K>(Func<User, K> selectMethod, List<User> userList)
{
  return userList.Select(selectMethod).ToList();
}

Aw snap, now I can get a list of anything I want, well at least a one type, one dimensional array. By the way, this is the first step in probably a series of posts that will end up with a much cleaner way of doing this.

• What Is Readable
• Linq Extension Methods Versus Linq Query Language… DEATHMATCH
• The Switch Remover: Convert Switch Statements to Dictionaries
• Uhg It Won’t End

private static IQueryable<User> GetUserList(Expression<Func<User, Boolean>> whereClause, Expression<Func<User, String>> orderBy)
{
    var query = (from user in GetDataContext().Users
             select user).Where(whereClause).OrderBy(orderBy);

    return query;
}

Now you will notice there is a new Expression in town and it's name isn't Reggie Hammond. It is my order by Expression which uses a Func<User, String>. It took me a minute to figure out how this works. I thought it was somehow in need of the property name to order by, but in reality it is looking for a list of strings to order by. Simple. I could do something like: (Ignore the WhereLikeFirstNameLastNameUserName for now)

    return GetUserList
           (
            WhereLikeFirstNameLastNameUserName(name),
            currentUser => currentUser.UserName
           ).ToList();

But that's boring. I want to be able to pass a method that would give the correct string to orderby somewhat cleaner. In comes a method that returns an Expression. OooOoOOo.

private static Expression<Func<User, String>> SortOnUserName()
{
    return currentUser => currentUser.UserName;
}

So now it looks like:

public static IList<User> GetUserListByLikeName(String name)
{
   return GetUserList
          (
           WhereLikeFirstNameLastNameUserName(name),
           SortOnUserName()
          ).ToList();
}

Cleaner... Now what is WhereLikeFirstNameLastNameUserName? Simple, that is my where Expression just being returned in this method:

private static Expression<Func<User, Boolean>> WhereLikeFirstNameLastNameUserName(String name)
{
   return currentUser => SqlMethods.Like(currentUser.UserName, "%" + name + "%")
   || SqlMethods.Like(currentUser.FirstName, "%" + name + "%")
   || SqlMethods.Like(currentUser.LastName, "%" + name + "%");
}

By the way, SqlMethods.Like is just a built in method used only with Linq to Sql. Probably shouldn't have used it in this example but oh well. Live with it.

OH NO NOT THE USINGS!!

using System;
using System.Collections.Generic;
using System.Data.Linq.SqlClient;
using System.Linq;
using System.Linq.Expressions;

• I likz demz linq
• Uhg It Won’t End
• I’m starting to worry about myself
• Linq Extension Methods Versus Linq Query Language… DEATHMATCH

private static IQueryable<User> GetUserList(Func<User, Boolean> whereClause)
{
  var query = from user in Users
            where whereClause(user)
            select user;

  return query;
}

public static IList<User> GetUserListByUserName(String userName)
{
  return GetUserList(currentUser => currentUser.UserName == userName).ToList();
}

AND YOU WOULD BE WRONG! I only know this because... eh... I saw a friend of mine try this and it failed. Fact is, the Linq where doesn't take in a Func, but rather it expects and Expression. So no big deal right? Slap on an expression and go... except you can't keep the same syntax. (Trust me, my... friend tried) Being the absolute genius that I am, I offered my friend a solution, and it's slightly ugly:

private static IQueryable<User> GetUserList(Expression<Func<User, Boolean>> whereClause)
{
  var query = (from user in Users
            select user).Where(whereClause);

  return query;
}

Could be used like:

public static IList<User> GetUserList()
{
  return GetUserList(currentUser => true).ToList();
}

Or

public static IList<User> GetUserListByFirstName(String firstName)
{
  return GetUserList(currentUser => currentUser.FirstName == firstName).ToList();
}

Yeah, not the prettiest of things, but it is what it is. I'm not even sure this is useful yet. Still screwing around with it. Does cut down on code for easy queries.

AND NOW FOR THE ASSEMBLIES!

using System;
using System.Collections.Generic;
using System.Linq;
using System.Linq.Expressions;

• And some days I love programming
• Uhg It Won’t End
• I’m starting to worry about myself
• Linq Extension Methods Versus Linq Query Language… DEATHMATCH

So what is done here:

Basically I am using a linq expression to get states from a list of states (Like Michigan, Illinois, or Canada) based on name. No big deal. Then I take the query and produce a List from it. AMAZIN!

stateList.ToList().ForEach(curretState => returnValue.Add(curretState));

ForEach is an extension method for List<>. Now if you remember from previous posts, that means it resides in a static class somewhere that "tacks" it on to the List<> class. Basically this method acts like a typical foreach loop. (You know, go through the list and do something. Or nothing. I suppose you could just loop through if you wanted to. I won't tell you how to live your life.) Simple but in my opinion, much cleaner looking.

I mean I could do this:

public static StateCollection GetByName(String partialName)
{
 StateCollection returnValue;

 returnValue = new StateCollection();

 foreach(State currentState in baseList)
 {
   if(currentState.Name.StartsWith(partialName)
   {
     returnValue.Add(currentState);
   }
 }

 return returnValue;
}

Really it's just up to what you prefer. (And I'm sure you could drive a car with no power brakes. You'll still get there.) Also, I really didn't need the linq expression since I could have done this all with ForEach (Provided baseList is IEnumerable).

One last note, all IEnumerable collections have the ToList() method (And a bunch of other ones for that matter.)

• Linq Join Extension Method and How to Use It…
• Linq Extension Methods Versus Linq Query Language… DEATHMATCH
• Cannot Resolve Method, Can’t Infer Return Type, and Funcs
• Uhg It Won’t End

First off, Lambda expressions. These are the odd looking currentItem => expressions you might see in my examples. They are a little misleading, at least to me they were. When I saw:

 ilist.SomeExtension(currentItem => SomeMethod(currentItem));

I thought that meant:

Loop through the list of currentItems and use that method. Well that's sort of it, but really misleading. In order to fully understand some of the more fun extension methods and lamba fun, a clearer explanation is needed. (I say fun instead of more complicated since I think the word "complicated" is exaggerating .)

What

 ilist.SomeExtension(currentItem => SomeMethod(currentItem));

really means is that I am going to call this method SomeExtension, give it a method to use, and that's it. What it does with that method is the heart of what SomeExtension is.

Small note: currentItem => helps to infer the type of whatever it is that you're going to pass into SomeMethod.

Say SomeExtension looks like this:

public static void SomeExtension(this IList<I> items, <I>, Action<I> action)
{
   SomeExtension(I item in items)
  {
    action(item);
  }
}

Now what is action? It's basically a place holder for a method that returns nothing. Only thing it cares about is what it has to send in, and that is Type I. From there, it will call the method it points to and magic happens.
Small note: What the hell is items? Well that is the list that you called this method from. This is an example of an extension method. Extension methods, in short, allow a person to "tack" a method onto a class without changing the class itself. this IList<I> items tells me that the extension method SomeExtension will be "tacked" onto ANY IList.

In this instance, what action really looks like is this:

public void action
(
  delegate (I Item)
  {
    SomeMethod(item);
  }
)

As you can see, the SomeMethod from the original SomeExtension call comes into play now. The above examples really could be the List<> extention method of ForEach most likely looks like.

Now what might not look familiar there is the delegate key word. This is what's called an anonymous method. Basically, this allows you to create delegates on the fly. An example of this would be List<>.Contains. A normal call to this might be:

someList.Contains(delegate(String currentItem){ return currentItem == someVariable); });

What this says is that contains will do whatever it does, but it will use the method you have provided to do that. Most likely the method itself looks like (And this is pseudo code for sure):

Boolean contains;

contains = false;

foreach(String currentItem in theList)
{
  contains = delegate(currentItem);

  if(contains)
  {
     exit;
  }
}

return contains;

Although, this is misleading in this post since this would deal with Func not Action.

• Another removing Lambda “trick”
• The Switch Remover: Convert Switch Statements to Dictionaries
• Using the ForEach method on List Collections
• Linq Join Extension Method and How to Use It…