An interesting pattern I've seen emerge since the early releases of Orcas is what I might refer to as "delegate properties".  What I mean by that is a property (or field, I suppose) that returns a delegate.  This pattern has some interesting implications.

First, in a language that treats delegates as directly callable objects, this pattern looks just like a method (someInstance.TheProperty(args)).  You can't tell the difference (although VS gives you different intellisense) by looking at a callsite like this. Among other things, this leads to some interesting naming issues.  Do you name it like you would a method?

Second, it opens up opportunities to do some really powerful (and slightly insane) hybrid inheritance models.  Think about a virtual delegate property that has both a getter and a setter, now think about trying to predict what that delegate will do when you call it.  It doesn't sound like something to recommend as part of a public API, but I think there are some interesting scenarios there.

If I come up with something interesting and useful, I'll let you know.

Today is our 8 year anniversary.  Eight years seems like a really long time!  This past year has been a crazy year for us.  We've moved across the country, away from all our friends and family.  And, through it all, Becky's put up with all my crazy shenanigans.

Thanks, Becky.

Three of my good friends came to visit in the past couple of weeks.  My friend Peter, who I met in the 5th grade (if I recall correctly) visited again last week.  Due to a bizarre coincidence, his wife had a one-week job in Bellevue, which is here on the east side of Seattle.  So, I got to hang out with him, which was a blast.

This week, my buddy Dave was here.  Dave and I played trombone together in college.  His visit was also somewhat coincidental, but I won't go into the details here.  He stayed with us and we hung out and we had all manner of good times.

While Dave was here, Jeff (one other trombone friends from college) came down from Bellingham to hang out for an evening, which was super-fun.  In another bizarre coincidence, his wife Bethany went to high school with Dave, so there was some reminiscing there as well.  Bethany's mom came along for the ride as well, and schooled us all in a game of Wii Sports bowling.

I was really bummed that these visits occurred right after our big vacation, which meant that I really couldn't afford to take a couple of days off to enjoy them.  So, sorry again for that guys.

We got back from our big summer vacation a few weeks ago, and I've finally got all my photos processed and uploaded.  Here's the collection that combines the Cape Cod and Texas parts of the trip:

We had a really great time, aside from the ridiculous hassles of air travel.  Jenna got to meet her 2 cousins, and WE got to actually spend time with my brother and his family, which was something that was limited due to the sickness we had during our Christmas visit.

If you have been following my series on delegates, you may have experimented with open-instance delegates and perhaps found it difficult to create an open-instance delegate for a value type.

If you'll recall, an open-instance delegate has an extra first parameter, used to pass the instance used for the invocation.  What's not made explicitly clear is that this first parameter must be passed by reference.

For reference types, you've automatically got a reference, but for value types, this must be a "ref" parameter.  For instance, a delegate type used as an open-instance delegate for Int32.CompareTo would have to be defined something like:

delegate int IntCompareToDelegate(ref int instance, int other);

Otherwise, you'll get a System.ArgumentException when you try to bind the method to the delegate, giving you the ever-helpful error message: "Error binding to target method".

There are lots of underlying reasons for this, both from a calling convention perspective, as well as a side-effect perspective.  But, you can simplify it by thinking about modifications to the instance.  If you passed by value (creating a copy that the method acted on), any changes made to the instance by the method would be lost because they happened to a copy.

In most cases, value types are immutable in the framework, but you could run into issues with your own types.  And, again, this isn't the only reason for this restriction (take a look at the IL generated for a value-type method call to get some more ideas).  It's just the easiest to understand.

If you'll recall, Orcas extension methods, which are similar in concept to this, do not follow this pattern and are subject to the infamous value type copying problems.