Moving Again

24 January 2015

I have moved my blog once again. It has been hosted on an Azure instance for about 2 years now. In that time I have had exactly one post, the one describing that I was now running my blog on the Azure instance using BlogEngine.net.

I have now moved once again, but this time I am using Jeykll. There are several advantages to running on Jeykll and GitHub. One, it is free. Second, the blog entires are under version control. Third, I can write my posts in Markdown instead of of authoring them in raw html. Fourth, I can preview changes to my blog locally before pushing them live.

I might have been able to do these things with BlogEngine.net, I don’t know. I never bothered to find out. I never found the blog engine convienent to author posts in and it posed another barrier to my blogging regularly.

In the move to BlogEngine.net I, unfortunately, lost all the comments for my blog. This is partically unfortunate for Fatherly Advice To New Programmers, my most popular and well received blog post.

I shut down comments to my blog at the time I moved to BlogEngine.net and Azure because I spent most of my time deleting spam comments than actually writing blog entires. I have re-enabled them with the move to Jekyll by using disqus as my comment server. Hopefully I will be able to manage my comments better and get less comment spam.

New address

07 February 2013

This blog had a good, long run on Brian Pepin servers he was gracious enough to host in is house. Brian's house, however, is going through some renovations so he decided to move his own web servers to Azure and shutdown his homegrown server farm. That means my free-loading days are over! I needed to do what I should have done a long time ago; move my blog to Azure.

If you see this post that means my blog has successfully moved! Onward and upward!

Simulating INumeric with policies

06 March 2009

After reading Luca Bolognese's blog post regarding using C# 4.0's dynamic keyword to simulate INumeric I immediately thought that must be a way to express this with generics instead. Generics, however, do not allow you to abstract over operators (which is what is is needed to really do INumeric) but you can simulate it using adapters as described in this post.

Say I want to write a general average routine that is generic over what type I am using to store the data. That is, I want one routine that works equally for double as well as decimal. What I want to be able to write is something like,

public static T Average(params T[] values) {
    T total = 0;

    foreach (var v in values)
        total = total + v;

    return total / values.Length;
}

where the T is any type that supports adding and dividing. I can't get this code to compile exactly but we can get surprisingly close! My final version looks like,

class Math<T, A> : PolicyUser<T, A> where A : struct, IOperatorPolicy<T> {
    public static T Average(params T[] values) {
        var total = L(0);

        foreach (var v in values)
            total = total + v;

        return total / values.Length;
    }
}

which is much closer to the original than I thought originally could get!

I started by cloning the operator policy and added a FromInt() I will explain below,

interface IOperatorPolicy<T> {
    T Add(T a, T b);
    T Subtract(T a, T b);
    T Multiply(T a, T b);
    T Divide(T a, T b);
    T FromInt(int value);
}

Then I cloned the double policy struct and then added a decimal mainly by cut/paste/search/replace

struct DoubleOperatorPolicy : IOperatorPolicy<double> {
    double IOperatorPolicy<double>.Add(double a, double b) { return a + b; }
    double IOperatorPolicy<double>.Subtract(double a, double b) { return a - b; }
    double IOperatorPolicy<double>.Multiply(double a, double b) { return a * b; }
    double IOperatorPolicy<double>.Divide(double a, double b) { return a / b; }
    double IOperatorPolicy<double>.FromInt(int value) { return value; }
}

struct DecimalOperatorPolicy : IOperatorPolicy<decimal> {
    decimal IOperatorPolicy<decimal>.Add(decimal a, decimal b) { return a + b; }
    decimal IOperatorPolicy<decimal>.Subtract(decimal a, decimal b) { return a - b; }
    decimal IOperatorPolicy<decimal>.Multiply(decimal a, decimal b) { return a * b; }
    decimal IOperatorPolicy<decimal>.Divide(decimal a, decimal b) { return a / b; }
    decimal IOperatorPolicy<decimal>.FromInt(int value) { return value; }
}

The cleaver bit is to define a base type that contains a struct that defines the operators as overloads. The overloads use a policy struct to implement that overloaded operators. This struct also defines implicit conversion operators to hide some (but not all) of the messiness introduced by using this wrapper type. The PolicyUser class looks like,

class PolicyUser<T, A> where A: struct, IOperatorPolicy<T> {
    static A Policy = new A();

    protected struct Value {
        public T V;

        public Value(T v) { V = v; }

        public static Value operator +(Value a, Value b) { return new Value(Policy.Add(a.V, b.V)); }
        public static Value operator -(Value a, Value b) { return new Value(Policy.Subtract(a.V, b.V)); }
        public static Value operator *(Value a, Value b) { return new Value(Policy.Multiply(a.V, b.V)); }
        public static Value operator /(Value a, Value b) { return new Value(Policy.Divide(a.V, b.V)); }
        public static implicit operator Value(T v) { return new Value(v); }
        public static implicit operator Value(int v) { return new Value(Policy.FromInt(v)); }
        public static implicit operator T(Value v) { return v.V; }
    }

    protected static Value L(int value) { return new Value(Policy.FromInt(value)); }
}

What the Value struct does is allows you to use the type Value in place of the type T whenever you want to use operators. When operators are used you only need to ensure one sub-expression is promoted to Value and the implict operator will take care of the rest.

One remaining oddness is using literals. Implicit operators have there limits which makes using literal a bit strange. This was also odd in the Policy post as well and I used the same trick to make it a little less cumbersome. I introduced a static method L() that takes an integer and converts it to Value allowing you to use integer literals by calling FromInt() I introduced earlier. You can extend to this to allow other types by repeating the pattern for, say double, allowing you to use double literals as well. I didn't because I didn't need it for my example (but probably will if I try to implement something more complicated.

To bind the actual data type to provide the data type and the policy. To make this simpler I created two create implementations of Math.

  class DoubleMath : Math<double, DoubleOperatorPolicy> { }
  class DecimalMath : Math<decimal, DecimalOperatorPolicy> { }

Calling the average method looks like,

    var resultDouble = DoubleMath.Average(1, 2, 3, 4, 5);
    var resultDecimal = DecimalMath.Average(1, 2, 3, 4, 5);

It should be straight forward to see how this could be adapted to a Financial class, as Luca was trying to build, and how the routines could be made independent of the data type used in the calculations.

There you have it. Policies can be used to simulate INumeric without having to resort to using dynamic.

Edit: Mar 9, 2009: Fixed HTML formatting error

Zero the value is not

31 October 2008

One of my pet-peeves is code written like this,

if (0 != value) { ... }

This reads backwards to me. I hear echoes of Frank Oz in my head, "if zero the value is not". As cute as this dialect is coming from a pointy-eared muppet, it still takes a bit to translate back into the more common English phrasing, "if the value is not zero". It seems programmers who insist on writing in this style have forgotten that their source should be readable as well as executable. Don't force your readers to have to do grammar gymnastics as well as having to decipher your algorithmic gynmastics.

Once upon a time, this was considered good style in order to avoid accidentally writing something like,

if (value = 0) { ... }

In C#, this is illegal. In most (all?) modern C and C++ compilers, this will generate a warning. (You do compile with warnings reported as errors right?) There ceases to be a good reason to write test expressions backwards. Let's let this style rest in peace.

Even if you think the above form has some redeeming value, let's all agree that any programmer that voluntarily writes something like,

if (false == value) { ... }

should have an electric shock sent directly through their keyboard.

BeginInvoke's last parameter: What's in a name?

16 June 2008

I have been playing around with asynchronous programming lately and it bothers me that the last parameter to the begin invoke pattern doesn't have a name that everyone agrees on. The begin invoke pattern is the asynchronous calling pattern were the BeginXxxx(), such as Stream.BeginRead(), takes a set of parameters, a callback method, and some, well, thing, at the end that is carried along with the asynchronous operation that eventually finds it way into the IAsyncResult. The problem is what do we call that thing? In an informal survey of the methods in the BCL that implement this pattern I have found a wide variation. Here is a partial list in somewhat order of popularity,

  • object
  • stateObject
  • state
  • asyncState
  • extraData
  • data

There seems to be little agreement about what to call it. We could pick the most prevalent but the name object occurs the most often because every delegate gets a BeginInvoke() method created for it and in this automatically generated code the parameter is called object. We can't standardize on object because it is a reserved word in several languages so either it would be impossible to specify or awkward (i.e. @object in C#). What I would like is a name that we can all use and we can all agree on.

To name the thing, we first must understand why it it is there at all. It exists to hold some state on behalf of the caller. Having the state object makes programming against the begin invoke pattern easier in languages that do not have anonymous methods that capture local variables. Consider the following program (which intentionally ignores errors because it is only an example),

const string uriFormat =
    "http://messenger.services.live.com/users/{0}@apps.messenger.live.com/presence";
const string responsePattern =
    @"""statusText""\s*:\s*""(?<status>\w+).*""displayName""\s*:\s*""(?<name>\w+)""";

static void Main(string[] args) {
    var uri = string.Format(uriFormat, args[0]);
    var request = WebRequest.Create(uri);
    var result = request.BeginGetResponse(PresenceCallback, request);

    // Other interesting work....

    result.AsyncWaitHandle.WaitOne();
}

private static void PresenceCallback(IAsyncResult result) {
    var request = result.AsyncState as WebRequest;
    var response = request.EndGetResponse(result);
    var s = new StreamReader(response.GetResponseStream()).ReadToEnd();
    var search = new Regex(responsePattern);
    var match = search.Match(s);
    if (match.Success)
        Console.WriteLine("{0} is {1}",
           match.Groups["name"].Captures[0].Value,
           match.Groups["status"].Captures[0].Value);
    else
        Console.WriteLine("Unexpected response");
}

This will get the online status of a Windows Live Messanger account given the live ID account number. For example, passing 1afa695addc07e5 as an argument to the above will tell whether or not I am online. In this case I am using last parameter of the BeginGetResponse() method to pass the request itself. This then is cast back to WebRequest in the PresenceCallback() method so I can call EndGetResponse() to retrieve the actual response. As far at the BeginGetResponse() call is concerned, this value is opaque. It ignores it completely and just supplies it blindly in the IAsyncResult. It makes no assumptions about the data at all, it is just something the caller just wants carried around. If I was using anonymous delegates in C# this would look a lot better as,

static void Main(string[] args) {
    var uri = string.Format(uriFormat, args[0]);
    var request = WebRequest.Create(uri);
    request.BeginGetResponse(result => {
        var response = request.EndGetResponse(result);
        var s = new StreamReader(response.GetResponseStream()).ReadToEnd();
        var search = new Regex(responsePattern);
        var match = search.Match(s);
        if (match.Success)
            Console.WriteLine("{0} is {1}",
               match.Groups["name"].Captures[0].Value,
               match.Groups["status"].Captures[0].Value);
        else
            Console.WriteLine("Unexpected response");
        }
    }, null);

    // Other interesting work....

    result.AsyncWaitHandle.WaitOne();
}

Here the request local variable request is captured automatically by the C# compiler and placed into a compiler generated class as a field. The compiler generated class also contains the code I supplied in the lambda as an instance method. When I refer to response in the lambda the reference is automatically translated into a field lookup in the generated class. Since request is already accessible in the lambda I don't need the last parameter to carry anything useful so I pass null.

Anonymous methods makes using callbacks much easier but since not all languages support anonymous methods or lambdas the BCL standardized on a method pattern for begin invoke that can easily be used by those languages. If the calling pattern did not have a caller state object then the work performed automatically by the C# compiler would have to be repeated manually by the programmer in these, then, second class languages. The .NET team did not want such languages to be second class citizen (especially since neither C# nor VB.NET supported anonymous methods initially) so they required the presence of the caller state object parameter.

Now we know why it is there, what to do we call it? I like state because the parameter represents state the caller want's to preserve. I don't like object because it is a common reserved word. I don't like stateObject because a symbol's type should not be repeated in the name, we already know it is an object by its type. asyncState is acceptable, especially since that is the name it is given by IAsyncResult, but it is a bit redundant, we already know, by context, it is asynchronous state. Plus we should avoid abbreviation, like "async", in symbol names (though it is very common, and asynchronous is very very long, so not that bad). data seems fine to me, it is a synonym to state, but it is overused. extraData I cannot, for the life of me, figure out. Extra for whom? Extra as opposed to what? Unfortunately, this is the name given to the parameter by IHttpAsyncHandler (see, I told you "async" was common).  Its name tells me nothing about what I should do with it. It is very unclear that this value should be mapped to AsyncState in IAsyncResult.

I propose we call it state, with an acceptable variation of asyncState.

Now, if changing a parameter name was not a breaking change...


Trivia:

  • The above uses the Live Services that you can find more about here.
  • The IM presence service returns JSON which I parse using a fancy looking Regex instance. I recommend that production code use DataContractJsonSerializer() instead.

Older posts

See archive for older posts.