Monday, July 23, 2007

Want a good job in Wellington?

Are you a good .NET developer looking for a job in Wellington, New Zealand?

My employer is currently looking for .NET developers (junior, senior or anywhere in between). We may also be interested if your skills are mainly in testing or business analysis.

What is the company like? Good! I'm very glad to recommend it. Skilled, friendly people to work with; great customer feedback.

As I've often suggested suggested in my agile blog, working in an IT services company is full of challenges and opportunities. We're addressing those challenges and opportunities unusually well.

If you enjoy working on successful projects, please get in touch via email. You can find my address on my other site, here.

Sunday, July 08, 2007

Claytons Interception

Ayende posted 7 different interception approaches for AOP in .NET. Here's one more...

...well, actually, it's a "cheat's way" to do interception. But, it's has proved to be useful in the real world and it avoids all of the disadvantages mentioned in Ayende's post.

It is "the interception you do, when you're not doing interception"(*). It simply means that you write your property getters and setters in such a way that "interception" is built right into the code. Here's an example from Mindscape LightSpeed:

public string DisplayName
get { return _displayName; }
set { Set(ref _displayName, value, "DisplayName"); }

The Set method can do whatever is required, both before and after it sets the actual value.


Simple, understandable, debuggable. Can still use "new" to create objects (unlike some alternatives).


Only works for properties. While properties are the main place where interception is required (at least in ORMs and related functionality) some people do want interception on methods too.

Another disadvantage is that you have to put the property name into the setter method. While this is not too bad if your objects are generated (just re-generate if names change) it's still a bit ugly to have string names in the code. I'm particularly uncomfortable with it if anyone is likely to rename the property (using Resharper's Rename feature for instance) while forgetting to also change the string name in the property setter. And, given Murphy's Law and human nature, forgetting probably is likely.

Property Name Solutions

What if you don't like that property name sitting inside the setter methods?

Rocky Lhotka put together a solution to the property naming problem. The solution is based framework code crawling back up the stack to find the property setter. In my own tests, that can be slow and, as Rocky notes, it can be broken by method inlining.

I have put together an alternative solution, which does not suffer from those drawbacks. It lets you write the code above like this (note that the property name string is not inside the setter method any more):

public string DisplayName
get { return _displayName; }
set { Set(ref _displayName, value); }

It works by leveraging the fact that the first parameter is a ref parameter. With a bit of managed C++, you can convert that ref param into a managed pointer. Then you can look at how far "into" the object it points, and use that to identify the property. (Technically, it identifies the field. But, if each field is used by one property, then we can easily associate field names with property names.)

Note that the managed C++ code is pure .NET code, marked as "unsafe" so that it can use pointers. It has to be written in C++, not C#, because while C# can use pointers, it cannot create one from a ref parameter.

You can find a full working implementation here. Please note that I am not a C++ developer. This was the first (and probably the last) managed C++ that I have written! While I have undertaken a number of tests to check the validity of this appoach, the fact remains that I'm not experienced in managed C++. Use at your own risk. Please post any questions below.

Update, Feb 08: I've posted an updated, re-written version here.

(*) Austrialian and New Zealand readers may recognise the theme in naming this post. It's based on Claytons, marketed many years ago as "The drink you have when you're not having a drink."