Public Class GeoffAppleby

She loves me, she loves me not.

I was reading a post that Darren made tonight about simplifying some code by using reflection. I want to first give a disclaimer to Darren to make sure he realises right from the start that a) the sample he gave is good and clever; and b) I'm not bashing him for doing it :)

Reflection is a very powerful tool. You can do a hell of a lot of stuff with it. The best use I've found for it in my own work was for creating my own ASP.net property grid web control. You never know what you're going to get, so being able to enumerate every property on a given object, and further, analyse every attribute on that property (custom or not) to make some rendering decisions is hella cool. The best example of it that I've seen in the wild would without a doubt have to be Lutz Roeder's Reflector. Not only does it pick apart an assembly, but he even reconstructs the source code.

Once you head down the reflection track, it's actually pretty damn easy to use. But there's a catch that doesn't seem to be mentioned that often by many people. Reflection is a performance penalty. If you have a specific need for it, use it! If it's not going to be called very often, use it! If it makes your code elegant and adaptive and easily extended (like Darren's example), use it!

But if you're in a situation where reflection stuff is called often, in succession, and high performance and/or scalability is a requirement, then think carefully first.

That's all I wanted to say - just think about when you're doing, why, and how often it's going to run. If it's not often, or it doesn't matter, dive straight in. If there's another way of doing it that won't sacrifice the performance so much (normally, in the situations where reflection is a real bonus but not absolutely required, the offset is a sacrifice against maintainability or cleanliness). I thought it was important enough to mention this fact myself, rather than just add a comment on Darren's post.

I'll get down off my soapbox now. It certainly is a nice little example of how to make things extremely flexible, and custom attributes are an amazingly powerful way of representing extra information without messing up your objects with extra properties or method calls that would be needed to get the same information back in an early-bound scenario.

I should also mention the best (and worse) use I've seen of it within the .net framework (at least, obviously in there :) - something dear to my heart (by necessity) lately, the XMLSerializer.

People who have following my sob stories and rants recently about it will know that it still has it's faults, namely

• The constructor gives a hell of a hit if dealing with complex types
• If the object you serialize implements IEnumerable, ICollection, or IDictionary, your in for some interesting times

I haven't seen any hope of a solution for the second point in the next version of the .net framework (the doco for the XMLSerializer for VS2K5 has the same text as before about it, but there is a light at the end of the tunnel for the constructor.

I discovered the other day that they'll be shipping a new tool called sgen.exe, which pre-generates the custom serialization code that is normally generated in the constructor. You run it against and assembly, and you have a new assembly that deals with all the types it found. You then reference that new assembly and call it when you need stuff serialized. Sweeeeeeet!

I refer you again to a previous post of mine, Time is not on my side, where I complain that I want whidbey now, dammit! :)

Update: This seems to have become a chain letter. I was responding to Darren, now Scott is chipping in his two cents too :)

Update 2: Dammit, I just thought of a better title for this post: Reflecting on Reflection. Oh well, too late now!