I recently posted a question about the use of readonly on stackoverflow. Follow the link to see the comments on Thoughts on the use of readonly for any/all instance members of a class?

For some time now I’ve been using the readonly modifier for nearly all class fields. I use it for List members, IDisposeable members, ints, strings, etc… everything but those I must change.

I personally find the following benefits to marking all (nearly enough) fields as readonly:

  • You do not have to check to see if the field is null outside of initialization
  • By reviewing the field definition you can tell if the value is going to change
  • Prevents accidental ‘side-effects’ of various methods on an object
  • Greater ability to use objects across threads

 
I confess that my habitual use of readonly stems from my passion about immutable objects in general. Though C# is not the greatest language in the world for supporting immutability; it still is a worth-while effort. Immutability of an object allows sharing across threads, predictable behavior, cache or reuse of objects, and other benefits. The other thing I like about it is that it’s damn hard to write a setter on an immutable object (death to the setters).

As another note related to readonly I would recommend ‘static readonly’ over ‘const’ declaration every time. The compiler treats ‘const’ definitions as C++ does a ‘#define’ and translates the use into the actual value at compilation time. Using the ‘static readonly’ approach allows you to change a constant in one assembly and it take affect in another without requiring you to recompile it.

 

For the past few days I’ve been working on a solution to a problem in WinForms. Most people are not aware of the following:

The “threading api” methods of the Control class are not thread safe. This includes calls to InvokeRequired, Invoke, BeginInvoke, and even EndInvoke. What do I mean by “not thread safe”? The worst offender is that a call to Invoke(), BeginInvoke().AsyncWaitHandle.WaitOne(), or EndInvoke() may never return control to the calling thread. This can happen when the control your calling this upon is actively in the DestroyHandle() routine at the time your thread calls these APIs. Additionally any of these calls can, if the control’s thread is actively in DestroyHandle, recreate the control on your thread. This can cause strange exceptions/behavior on the original control’s thread.

The solution is not an easy one. I built a few test cases to produce these issues and set out to solve it. Now, after a few days, I can finally put this to rest. I’ll try to include this in the next Library build, but until then the solution and more information on the issues are available here:
Avoiding the woes of Invoke/BeginInvoke in cross-thread WinForm event handling?

<rant>
And thanks for playing Microsoft but you FAIL. Threading APIs that are not thread safe… you kill me. Maybe they’ll fix it .Net 10.0 sp3 after they finish making it so that we can write a whole program on line of code. Maybe they could quit adding syntactic sugar and fix what they already have in the next release.
</rant>
(Wew, I needed that)

Update: Another reasonable answer posted today on stackoverflow.