[jmcqk6]

Are you kidding? Reflection is one of the most powerful parts of the .NET framework. Hell, the page you link to contains many examples of the different possibilities, but they're just a start. The only knock I know of against reflection is that it's a performance hit. If that's really the issue, write the code using reflection (it's going to be better code, most likely), and then see if performance is an issue. If it is, refactor out the reflection.

Reflection makes things possible that simply aren't possible without it. It can get rid of layers upon layers of complexity. It can shrink thousands of lines of code to fractions of that.

There is no reason to say that 'it should be used seldom.' It's a powerful tool and should be wielded along with every other tool in the toolbox.

[DrJokepu]

Yeah, I don't know about that. When I first discovered reflection, I was using it for everything. Initially it was awesome but then I've quickly realised that it's exactly the kind of thing that makes code a lot more complicated than it should be, especially with the deadly reflection + expression trees (runtime code generation) combo. It's really a dark path that you should stay away from. Basically, unless your problem involves having to get metadata about .NET assemblies, reflection is not the right solution. Code that's clever for the sake of cleverness is cool and entertaining but has no place in production.

[jmcqk6]

>When I first discovered reflection, I was using it for everything.

Well there's your problem. You have to use the right tool for the job. Reflection shouldn't be used for everything, and I wasn't suggesting that was the case. My point was that it shouldn't be avoided. It's damn helpful in a lot of different places, and to say outright that you're just not going to use it would be depriving yourself of a powerful toolset.

[edwinnathaniel]

Sometimes I find it a littl bit interesting that .NET community typically lag behind Java community in general (be careful interpreting general vs all).

In Java, the best known book that can be considered comparable with Jon Skeet book is written by Josh Bloch of SUN, Google, and API design fame. He literally suggested to avoid Reflection and use other features unless you are in the business of writing IDE, compiler, code analysis, etc.

I hvae done Reflection in the past and fow not to do that stupid move again and will spend more time figuring other solution. It is not about I cannot grasp Reflection but the code tend to be less elegant, less readable, and not compiled safe.

I would use dynamic languages if I found myself using Reflection a lot.

[edwinnathaniel]

Brrr. I wish I could edit all the typos I've made using iPad :(

[Zak]

It seems to me that many well-known "best" practices need to be considered with more context.

In an environment with a large, frequently changing team, heavy use of features that provide extra abstraction may result in less-skilled team members being confused. Most enterprise environments consider that normal. Most startups would fire a programmer who couldn't grasp reflection.