New Fun Blog – Scott Bilas

I’m a big fan of fluent interfaces. C# picked this style up in a big way starting with 3.5 and the Enumerable operators class. People are going nuts with it, often for replacing verbose old XML with something a little more readable and compact. Yay. Finally, C# has caught up with languages like Lua or Javascript which have had this ability forever.

Aside from a better configuration language, what I really like about coding fluently is that it’s a steady stream of left-to-right operators, like a pipeline. You think of the next operation and just chain it along, never having to back up. Domain specific sublanguages like LINQ (which I adore, incidentally) can make this even more compact, but I’m talking about the function-based fluent operators.

For enumerables, it’s easy:

var names = list.Where(i => i.Foo > 5).Cast<IBar>().Select(j => j.Name);

Take the list, filter it, cast to the type we want, and pull out an element. Operation by operation, left to right. But what about for a single object? That fluency hits a brick wall when you run into C#’s old C-style casting on an individual object.

var name = ((IBar)list.First()).Name;

Yuck. Not fluent, and hard to read. As you’re typing, you have to back up, stick the casted type on the front in parens, and, oh yeah, have to also go wrap the whole thing in parens to be able to continue the method chain. I’ve always hated having to do this and in the past would usually pull out the casting into a separate local.

It’s also easy to fix. We just need a little extension method:

public static partial class Extensions
{
    [DebuggerStepThrough]
    public static T To<T>(this object o)
        { return (T)o; }
}

Now it’s nice and fluent:

var name = list.First().To<IBar>().Name;

So we now have the system Cast<T> operator for casting elements within an enumerable, and To<T> for casting the overall type. Solid.

Do you have a locked down WordPress site that has a case-sensitive login even though the Googles are telling you that in WordPress 2.8 they went case-insensitive? Most likely you have John Kolbert’s nice Absolute Privacy plugin installed. It just needs a minor fix.

Edit absolute_privacy.php. Easiest way is through the admin interface under Edit Plugins. Change this line:

if ( !$user || ($user->user_login != $username) ) {

To this:

if ( !$user || (strtolower($user->user_login) != strtolower($username)) ) {

Now you can log in with whatever case you like.

In my last post I wrote about building AnyCPU assemblies that can reference 32 or 64 bit DLL’s automatically based on the environment. Just wanted to make a quick followup for people who are actually following my example, specifically trying to implement it for P4.Net. There are a few little snags if you’re not super familiar with native programming.

Make sure you do the following:

• You must have the 64 bit compilers installed or you won’t be able to add 64-bit configurations to p4dn. Most likely you didn’t check the box for this when originally installing Visual Studio. Just go to add/remove programs, “change”, and check 64-bit under the C++ area.
• The p4dn library requires Perforce’s p4api native library, which comes in many flavors. It is included in the distribution for P4.Net, but it is an old version. I recommend getting the latest API from their FTP site.
• I used the p4api_vs2008_dyn and p4api_vs2008_dyn_vsdebug configurations from the ntx64 and ntx86 builds.
• Why dynamic instead of static? .NET is all about DLL’s – using static just causes problems with the linker with conflicting runtimes.
• Update the include and lib paths in the p4dn C++ project settings so that the library can find your p4api. If you don’t do this you’ll get #include errors about missing paths.