Loads



Documenting Attached Properties with Sandcastle
2009-07-23T23:00:00.000+01:00
I’ve been using Sandcastle and Sandcastle Help File Builder (SHFB) recently to produce some SDK documentation and noticed that topics were automatically created for attached properties like the one shown here. But how do you actually populate these topics and how do you link back to them? Well let’s work through a simple example.
  /// <summary>
/// Identifies the MyAttached attached property.
/// </summary>
public static readonly DependencyProperty MyAttachedProperty = 
  DependencyProperty.RegisterAttached("MyAttached", typeof(string), typeof(MyClass));

public static string GetMyAttached(DependencyObject element)
{
  // Argument validation omitted.
  return (string)element.GetValue(MyAttachedProperty);
}

public static void SetMyAttached(DependencyObject element, string value)
{
  // Argument validation omitted.
  element.SetValue(MyAttachedProperty, value);
}

With attached properties there’s no physical property in the code for you to document. The only members that can be documented with the code are the dependency property field and the get/set helper methods. So how do you add documentation to the attached property topic? Well you can manually create an additional XML comment file for the assembly containing the attached property and add the following content:

<?xml version="1.0"?>
<doc>
  <assembly>
    <name>MyTest</name>
  </assembly>
  <members>
    <member name="P:MyTest.MyClass.MyAttached">
      <summary>Summary for MyAttached attached property.</summary>
    </member>
  </members>
</doc>

Add the XML comment file to the Documentation Sources of your SHFB project and the summary comments will appear in the attached property topic when the project is rebuilt. But what about linking back to the attached property topic from the dependency property field’s summary comment? Unfortunately the C# compiler will warn about both of the following:

/// <summary>
/// Identifies the <see cref="MyAttached" /> attached property.
/// </summary>

/// <summary>
/// Identifies the <see cref="MyTest.MyClass.MyAttached" /> attached property.
/// </summary>

In both cases the compiler warns that it cannot find a member matching the member specified in the see tag. This shouldn’t be that surprising because we already know there’s no physical property in the code. Sandcastle will therefore be unable to provide a link and the resulting text will appear as bold.  Fortunately there is a way to provide a valid member reference for the attached property, in fact we’ve already done so in the separate XML comment file.

/// <summary>
/// Identifies the <see cref="P:MyTest.MyClass.MyAttached" /> attached property.
/// </summary>

Now the C# compiler is happy and Sandcastle can generate a link back to the attached property topic.
  


The Dispose Pattern in C++/CLI
2009-07-14T23:00:00.000+01:00
In my last post I talked about implementing events in C++/CLI. I also briefly mentioned that the C++/CLI team went to great lengths to correctly implement the dispose pattern as described in the Framework Design Guidelines, using the familiar C++ destructor syntax. This syntax is well documented so I won’t bother to go into detail about it, instead I’m going to focus on a quirk you’ll see when deriving from a class with a destructor. Here’s what you’ll see in a derived C# class when overriding the Dispose method.
  protected override void Dispose(bool __p1)
{
  // Dispose implementation omitted.
  base.Dispose(__p1);
}

Clearly someone thought a single underscore wasn’t enough J. Somewhat surprisingly, there are no warnings generated for the __p1 parameter when code analysis is enabled, although I guess it explains how the parameter name slipped through in the first place. It could be that the code analysis tool knows the dispose pattern is being generated by the compiler and so ignores it completely, but I’m only speculating.

So will they fix it in a future release? I think it’s unlikely. Why? Changing the parameter name would result in a breaking change when class libraries are recompiled with the new compiler. So is it likely users of languages with support for named parameters are referring to the __p1 parameter by name? Probably not but Microsoft’s track record on breaking changes is to avoid them unless they’re required to fix a security vulnerability, so I think this will remain as a quirk of C++/CLI.
  


Implementing Events with C++/CLI
2009-07-10T23:00:00.000+01:00
I’ve been doing a fair amount of work in C++ recently, using C++/CLI for interop between managed and unmanaged code. I found a minor problem when implementing events in a class library that I thought I’d share. As with C# you have a couple of options for events: use the data member syntax or define individual event accessor methods. Just like C# the former approach is nice and simple whereas the latter approach provides more flexibility. Unfortunately it’s the former approach that has the problem. Consider the following example:
  public ref class MyClass
{
public:
  event System::EventHandler<MyEventArgs ^> ^MyEvent;
 
  // Remainder of MyClass omitted.
};

With this syntax the compiler will automatically produce the add, remove and raise event accessor methods. The latter is protected so that derived classes can also raise the event, and this is where the problem occurs. There’s already a well defined pattern that class library authors should implement to allow derived classes to raise events defined in a base class. Unfortunately the data member event syntax in C++/CLI doesn’t follow this pattern. The following C# snippets show the recommended pattern and the equivalent of what the C++/CLI compiler produces:

// Recommended method for raising MyEvent.
protected virtual void OnMyEvent(MyEventArgs e)
{
  // Raise event.
}

// Method for raising MyEvent produced by C++/CLI compiler.
protected void raise_MyEvent(object sender, MyEventArgs e)
{
  // Raise event.
}

The C++/CLI compiler produces a method that, in addition to having an ugly name, only allows derived classes to raise the event. Derived classes cannot handle the event without attaching their own event handler . When you consider the lengths the C++/CLI team went to implement the dispose pattern as described in the Framework Design Guidelines, it’s surprising they didn’t provide the same support for events. Fortunately, although somewhat tediously if you have a large number of events, you can overcome this limitation by defining the individual event accessor methods as well as the correct virtual method for derived classes. You’ll also need to provide the backing field for the event.

public ref class MyClass
{
public:
  event System::EventHandler<MyEventArgs ^> ^MyEvent
  {
  public:
    void add(System::EventHandler<MyEventArgs ^> ^value);
    void remove(System::EventHandler<MyEventArgs ^> ^value);

  private:
    void raise(System::Object ^sender, MyEventArgs ^e);
  }
 
protected:
  virtual void OnMyEvent(MyEventArgs ^e);

private:
  System::EventHandler<MyEventArgs ^> ^m_myEvent;

  // Remainder of MyClass omitted.
};

It’s a shame you have to jump through these hoops to implement a pattern that has existed since the first version of the .NET Framework. I also mentioned the lengths the C++/CLI team went to implement the dispose pattern earlier. Unfortunately this too has a problem, albeit a minor one, that I’ll talk about in the next post.
  


Restricting the Contents of Container Controls
2009-02-19T23:00:00.000Z
It’s quite common for container controls to place a restriction on the type of child controls they contain. For example, the TabControl class will only accept instances of the TabPage class as children. These controls will typically expose a type-safe collection to prevent users from adding the wrong type of child control. This is not a complete solution however, because it’s also possible to add child controls using the Controls property. In fact, this is exactly how the designer-generated initialisation code adds child controls. To prevent any bypassing of the child control restrictions you should override the CreateControlsInstance method and return a more specialised control collection that provides the correct behaviour for adding and removing child controls. Consider the following example, where the CustomPanel control is prohibited from having another CustomPanel control as a child control.
  public class CustomPanel : Panel
{
  protected override Control.ControlCollection CreateControlsInstance()
  {
    return new CustomPanelControlCollection(this);
  }

  private class CustomPanelControlCollection : Control.ControlCollection
  {
    public CustomPanelControlCollection(CustomPanel owner)
      : base(owner)
    {
    }

    public override void Add(Control value)
    {
      if (value is CustomPanel)
      {
        throw new ArgumentException(
          "Cannot add a CustomPanel control to another CustomPanel control.", 
          "control");
      }
      base.Add(value);
    }

    public override void Remove(Control value)
    {
      base.Remove(value);
      if (value is CustomPanel)
      {
        // Additional remove code omitted.
      }
    }
  }

  // Remainder of CustomPanel omitted.
}

I’ve overridden the Remove method for completeness, but it can be omitted if there’s no need to perform any additional work when removing child controls from the collection. What about the other methods that can be used for adding and removing child controls? Well the AddRange method and the implementation of the IList.Add method call the virtual Add method. It’s not possible to add child controls at any position other than the end of the collection, so the implementation of the IList.Insert method and the setter for the IList.Item property both throw NotSupportedException. The Clear, RemoveAt, RemoveByKey methods and the implementation of the IList.Remove method all call the virtual Remove method.

This means we only need to override the Add and Remove methods as shown above, but it also highlights a weakness with the design of the Control.ControlCollection class. When you have multiple virtual methods calling other virtual methods it can be difficult for inheritors to know which methods they should override. You’ll probably learn by unit testing the cases mentioned above or simply by using a tool such as Reflector, but in both cases what you’re learning about is the implementation details of the Control.ControlCollection class. It’s unfortunate when classes leak implementation details like this because it always leaves you with a problem. You can take the approach demonstrated above and hope that the Windows Forms team doesn’t change the implementation in a way that breaks your collection. Alternatively you can override and seal the other virtual methods and re-implement any relevant explicitly implemented interface members to produce the desired call chain. Unfortunately preserving the contract of the overridden methods can be more difficult than it first seems, especially if the base class implementations have access to members that are not accessible from derived classes. I think the former approach is the lesser of two evils based on the trend for minimising breaking changes in the .NET Framework, but YMMV.
  


Declaring Default Values for Control Properties
2009-02-18T23:00:00.000Z
Default values for properties must be documented to make users aware of a control’s default state. This information is also useful for visual designers and code generators. A visual designer can use the default value to perform a “reset” in the property grid, and a code generator can use the default value to determine whether or not it should persist the property in designer-generated initialisation code.
  Consider the following example, where the CustomListView control exposes a hover delay for generating a hover event during a drag-and-drop operation.
  public class CustomListView : ListView
{
  private int m_dragHoverTime = 400;

  public int DragHoverTime
  {
    get { return m_dragHoverTime; }
    set { m_dragHoverTime = value; }
  }

  // Remainder of CustomListView omitted.
}

The default value of 400 milliseconds can be documented but a visual designer will not be aware of this value. This results in the property being displayed in bold in the Visual Studio property grid, which indicates a non-default value. The value is also persisted in the designer-generated initialisation code. Use the DefaultValueAttribute class to advertise the default value of a property to visual designers and code generators.

public class CustomListView : ListView
{
  private const int DefaultDragHoverTime = 400;
  private int m_dragHoverTime = DefaultDragHoverTime;

  [DefaultValue(DefaultDragHoverTime)]
  public int DragHoverTime
  {
    get { return m_dragHoverTime; }
    set { m_dragHoverTime = value; }
  }

  // Remainder of CustomListView omitted.
}

With this approach the control’s hover delay time is only persisted in designer-generated initialisation code if it is different from the default value. Similarly, a visual designer will display the value correctly in the property grid and will also be able to perform a reset back to the default value. It’s worth noting that there’s a system-defined hover delay value returned by the SystemInformation.MouseHoverTime property. This seems like a better candidate for a default value than the previous 400 millisecond value. Unfortunately, it’s not possible to use this value with the DefaultValueAttribute class but there is another option – the ShouldSerialize and Reset methods pattern.

public class CustomListView : ListView
{
  private int m_dragHoverTime = SystemInformation.MouseHoverTime;

  public int DragHoverTime
  {
    get { return m_dragHoverTime; }
    set { m_dragHoverTime = value; }
  }

  private bool ShouldSerializeDragHoverTime()
  {
    return DragHoverTime != SystemInformation.MouseHoverTime;
  }

  private void ResetDragHoverTime()
  {
    DragHoverTime = SystemInformation.MouseHoverTime;
  }

  // Remainder of CustomListView omitted.
}

This still isn’t ideal because the value returned by SystemInformation.MouseHoverTime reflects a system-wide parameter that can vary across machines. This could result in unpredictable behaviour when using visual designers in a team environment. For example, resetting to the default value on one developer’s machine could result in another developer seeing a non-default value on their machine. Even so, it seems wrong not to provide developers with the facility to use the system-defined value. At this point you might be asking “Why not always used the system-defined value?” That’s definitely a sensible strategy, in which case you don’t even need to expose the DragHoverTime property. But we haven’t come this far just to ditch the property J. The actual scenario where I’ve used something similar to this example before involved using the system-defined value in all but one place. The exception was where usability feedback demonstrated that the system-defined value wasn’t long enough for the desired user interaction. The solution was to provide a UseSystemMouseHoverTime property to indicate whether or not the control should use the system-defined value or its own value, which means we can go back to the DefaultValueAttribute class after all J.

public class CustomListView : ListView
{
  private const int DefaultDragHoverTime = 400;
  private int m_dragHoverTime = DefaultDragHoverTime;
  private bool m_useSystemMouseHoverTime = true;

  [DefaultValue(DefaultDragHoverTime)]
  public int DragHoverTime
  {
    get { return m_dragHoverTime; }
    set { m_dragHoverTime = value; }
  }

  [DefaultValue(true)]
  public bool UseSystemMouseHoverTime
  {
    get { return m_useSystemMouseHoverTime; }
    set { m_useSystemMouseHoverTime = value; }
  }

  // Remainder of CustomListView omitted.
}

Obviously that’s a very specific scenario, but the key thing to remember is that you should make sure your controls have sensible defaults and that those defaults are properly reflected in a designer.
  


Hiding Base Class Members in Controls
2009-02-13T23:00:00.000Z
Even when you pick your base class wisely, it’s entirely possible for the base class to contain properties and/or events that are not meaningful for your custom control. Having these members available at design-time via a visual designer’s property grid or a code editor’s IntelliSense makes it harder for API users to spot the genuinely useful members. Consider the CustomPanel control below, where the size and enabled state are determined by the control’s parent. There’s no point advertising the AutoSize and Enabled properties for this control, so we should hide them.
  public class CustomPanel : Panel
{
  [Browsable(false)]
  [DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)]
  [EditorBrowsable(EditorBrowsableState.Never)]
  public override bool AutoSize
  {
    get { return base.AutoSize; }
    set { base.AutoSize = value; }
  }

  [Browsable(false)]
  [DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)]
  [EditorBrowsable(EditorBrowsableState.Never)]
  public new bool Enabled
  {
    get { return base.Enabled; }
    set { base.Enabled = value; }
  }

  // Remainder of CustomPanel omitted.
}

The following attributes have been used to hide the properties at design-time.


  The BrowsableAttribute class is used to hide the properties from a visual designer’s property grid. 

  The DesignerSerializationVisibilityAttribute class is used to prevent the property from being persisted in designer-generated initialisation code. 

  The EditorBrowsableAttribute class is used to prevent the property from appearing in the code editor’s IntelliSense. 


Defining the attributes on the AutoSize property is straightforward since it is virtual and can be overridden. The Enabled property is non-virtual so we cannot define the attributes on this property and must instead create another Enabled property to hide the inherited one. In both cases the original contract is preserved by calling through to the base class members.

When hiding members it is also important to consider any related members such as events. In the above example, we must consider the property changed events for AutoSize and Enabled properties, which will still be visible at design-time. The same techniques used for both properties are also applicable to their events as shown below.

public class CustomPanel : Panel
{
  [Browsable(false)]
  [EditorBrowsable(EditorBrowsableState.Never)]
  public new event EventHandler AutoSizeChanged
  {
    add { base.AutoSizeChanged += value; }
    remove { base.AutoSizeChanged -= value; }
  }

  [Browsable(false)]
  [EditorBrowsable(EditorBrowsableState.Never)]
  public new event EventHandler EnabledChanged
  {
    add { base.EnabledChanged += value; }
    remove { base.EnabledChanged -= value; }
  }

  // Remainder of CustomPanel omitted.
}

Windows Forms controls should follow the event pattern described in the Framework  Design Guidelines and raise their events from protected virtual methods. You should consider hiding these methods as well but in practice, hiding these members is unnecessary since it will still be useful for derived controls to interact with these events even when they’ve been hidden from the designer/code editor.

It is important to reiterate that the motivation for hiding base class members is to prevent meaningless members from appearing at design-time. It is not the intention to enforce runtime restrictions because we should always preserve the contract of the base class members. This is why neither property setter throws an exception.
  


Implementing Observable Objects – Part VI
2009-02-12T23:00:00.001Z
In Part V I mentioned that the ObservableItem class makes no checks to ensure any UI updates are made on the correct thread, which means it could potentially violate the threading model employed by both Windows Forms and WPF. Now if you spent much time working with WPF you’re probably aware that the data binding mechanism can actually cope with PropertyChanged events raised on different threads to the bound UI object. Windows Forms on the other hand will dutifully throw an InvalidOperationException in the same scenario if the CheckForIllegalCrossThreadCalls property is set to true. So if you only want to target WPF then you can get away with doing nothing, but I wouldn’t recommend this approach. Firstly, if you later discovered you needed to use the same data model with Windows Forms you might find it to be a non-trivial change, especially if other WPF dependencies have crept in. I know this appears to violate the YAGNI approach but we’re not really talking about adding unnecessary functionality, we’re trying not to unnecessarily prohibit reuse of the data model. Secondly, dealing with concurrency is hard enough without letting it ambush you J. I’m not saying you should never perform data model operations on a background thread, but you should always ensure that any resulting UI updates are marshalled to the correct thread. We can ensure we’re on the correct thread by making the following modifications to the ObservableItem class:

private readonly Thread m_synchronizationThread = Thread.CurrentThread;
private PropertyChangedEventHandler m_propertyChangedEventHandler;

public event PropertyChangedEventHandler PropertyChanged
{
  add
  {
    VerifySynchronizationThread();
    m_propertyChangedEventHandler += value;
  }
  remove
  {
    VerifySynchronizationThread();
    m_propertyChangedEventHandler -= value;
  }
}

[MethodImpl(MethodImplOptions.NoInlining)]
private void SetPropertyInternal<T>(
  string propertyName, ref T field, T value, IEqualityComparer<T> comparer)
{
  if (VerifySetPropertyArguments)
  {
    VerifySetPropertyInternalArguments(propertyName, comparer);
  }
  VerifySynchronizationThread();
  if (!comparer.Equals(field, value))
  {
    T oldValue = field;
    field = value;
    try
    {
      OnPropertyChanged(new PropertyChangedEventArgs(propertyName));
    }
    catch
    {
      field = oldValue;
      throw;
    }
  }
}

private void VerifySynchronizationThread()
{
  if (m_synchronizationThread != Thread.CurrentThread)
  {
    throw new InvalidOperationException(
      "The current object is being updated on a thread that is different from the " + 
      "thread it was created on.");
  }
}

Now whenever the SetPropertyInternal method is called or an event handler is registered or unregistered for the PropertyChanged event, the VerifySynchronizationThread method is called to ensure we’re on the correct thread. This protects us from unintentional UI updates on another thread, but what about when we need a data model object to perform a potentially long running operation on a background thread? Clearly we don’t want to be calling methods such as Control.Invoke or Dispatcher.Invoke from data model objects because that would tie us to either Windows Forms or WPF. This is where the SynchronizationContext class comes in, which allows us to Send (synchronous) or Post (asynchronous) updates to the UI correctly. Consider the following addition to the Person class:

public void LongRunningOperation()
{
  var currentContext = SynchronizationContext.Current;
  if (currentContext == null)
  {
    currentContext = new SynchronizationContext();
  }
  ThreadPool.QueueUserWorkItem(
    new WaitCallback(
      state1 =>
      {
        string processedFirstName = GetUpperLowerString(FirstName);
        string processedLastName = GetUpperLowerString(LastName);
        currentContext.Post(
          new SendOrPostCallback(
            state2 =>
            {
              FirstName = processedFirstName;
              LastName = processedLastName;
            }), 
          null);
      }));
}

private static string GetUpperLowerString(string value)
{
  var result = new StringBuilder(value.Length);
  for (int i = 0; i < value.Length; ++i)
  {
    string textElement = StringInfo.GetNextTextElement(value, i);
    result.Append((i % 2) == 0 ? 
      textElement.ToUpperInvariant() : 
      textElement.ToLowerInvariant());
  }
  return result.ToString();
}

Now I’ve cheated a little here since my “long running” operation does nothing more than alternate the case of characters in the FirstName and LastName properties J. We use the SynchronizationContext.Current property to return a SynchronizationContext object that will update the FirstName and LastName properties, and therefore any data bound view, on the correct thread. If the property returns null then we use a default SynchronizationContext. We do this because if the default SynchronizationContext doesn’t do the correct thing, which is likely, then the resulting InvalidOperationException will be more helpful than a NullReferenceException. I’ve added a button to both sample applications so that you can test this exciting functionality out J.

Now you might be wondering why we don’t store the current SynchronizationContext instead of the current thread. Unfortunately we’re unlikely to get the same instance back in a WPF application due to the way WPF sets the current SynchronizationContext and because none of the derived classes override the Equals method, reference equality is all we can use.

Well I think that’s enough on this topic, at least for a little while J. I promise the next post will be about something different.



Implementing Observable Objects – Part V
2009-02-06T23:00:00.001Z
In Part IV I mentioned that the SetPropertyInternal method can call unknown code. This is true for any method that raises an event. Why is this a problem? It’s a problem for the SetPropertyInternal method because we raise the event after changing the property’s value. This makes sense because event handlers will want to know what the new value of the property is. If an event handler throws an exception however, we’re left in a state where a property has been changed as part of an operation that did not complete successfully. So how should we deal with this? We should provide one of three established guarantees in the face of errors:


  The basic guarantee – data and invariants remain valid when the operation fails. 
  The strong guarantee – data is rolled back to its original state when the operation fails. 
  The no-fail guarantee – the operation cannot fail. 
 

Anything less than the basic guarantee has to be treated as a bug that must be fixed. The ObservableItem class currently honours the basic guarantee, i.e. the data remains valid for the object because it was an event handler that failed rather than the property’s own validation logic. So we don’t need to do anything, right? Well we should always strive to provide the strongest guarantee possible, unless providing a guarantee stronger than the basic guarantee unreasonably punishes callers for the majority of usage scenarios. Providing the no-fail guarantee is not possible here because we have no control over the event handlers. Can we provide the strong guarantee? Yes, by changing the SetPropertyInternal implementation as shown below:

private void SetPropertyInternal<T>(
  string propertyName, ref T field, T value, IEqualityComparer<T> comparer)
{
  DebugVerifySetPropertyCoreArguments(propertyName, comparer);
  if (!comparer.Equals(field, value))
  {
    T oldValue = field;
    field = value;
    try
    {
      OnPropertyChanged(new PropertyChangedEventArgs(propertyName));
    }
    catch
    {
      field = oldValue;
      throw;
    }
  }
}

When errors cannot be avoided objects that support transactional behaviour, i.e. the strong guarantee, will result in more reliable programs. It’s worth noting that there are a few extreme scenarios where an exception is thrown but the code in the catch block is not executed. For example, if memory has become so scarce that any attempt to allocate more memory results in an OutOfMemoryException being thrown, subsequent attempts to allocate memory will also fail. Could any subsequent memory allocations occur in the catch block above? Yes. They will occur when the jitter attempts to generate the native code for the block. Obviously this is a catastrophic failure that will hopefully result in termination of the running process, so the chances of anyone observing or serialising the changed value are slim. For that reason I’m going to leave the catch block as it is. If you need greater reliability than offered by the catch block then you can look at the reliability APIs from the System.Runtime.CompilerServices namespace, such as the RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup method.

One wrinkle still remains, which is related to the threading model used for both Windows Forms and WPF. This threading model requires that operations on UI objects be made on the thread that created them. The ObservableItem class is intended for use with data binding, which means we expect it to interact with UI objects. The class currently performs no checks to ensure that this interaction occurs on the correct thread. In Part VI we’ll see how we can address this.



Implementing Observable Objects – Part IV
2009-02-02T23:00:00.002Z
In Part III we looked at providing better diagnostic assistance for the SetProperty method on the ObservableItem class by asserting the relevant assumptions. Unfortunately this approach doesn't help third party users of our data model unless we give them access to debug builds. What we can do is modify the approach to match what the Windows Forms team did for detecting illegal cross-thread calls and use exceptions instead of asserts. Essentially this means the default behaviour will be to throw an exception only when the debugger is attached, providing third parties with the opportunity to see exceptions when they are debugging. This is a reasonable compromise because we want to detect incorrect usage of the SetProperty method but we don’t want to unnecessarily penalise the release build performance. The following static property indicates whether or not we want to verify the arguments to the SetProperty method.

private static bool s_verifySetPropertyArguments = Debugger.IsAttached;

[EditorBrowsable(EditorBrowsableState.Advanced)]
public static bool VerifySetPropertyArguments
{
  get { return s_verifySetPropertyArguments; }
  set { s_verifySetPropertyArguments = value; }
}

The default value is determined by the Debugger.IsAttached property but it can be changed to perform verification even when a debugger is not attached. This provides a limited amount of control over the behaviour of the ObservableItem class, plus it also makes it easier to test the verification code. I’ve used the EditorBrowsableAttribute class with the EditorBrowsableState.Advanced value to hide the property from IntelliSense when advanced members are not enabled in the code editor. This is a reasonable approach because the default value is sufficient for all but the most advanced scenarios. The SetPropertyInternal method can now use the property to determine whether or not to run the verification code, which is no longer confined to debug builds.

[MethodImpl(MethodImplOptions.NoInlining)]
private void SetPropertyInternal<T>(
  string propertyName, ref T field, T value, IEqualityComparer<T> comparer)
{
  if (VerifySetPropertyArguments)
  {
    VerifySetPropertyInternalArguments(propertyName, comparer);
  }
  if (!comparer.Equals(field, value))
  {
    field = value;
    OnPropertyChanged(new PropertyChangedEventArgs(propertyName));
  }
}

The VerifySetPropertyInternalArguments method no longer uses the ConditionalAttribute class although it does still have some asserts.

[MethodImpl(MethodImplOptions.NoInlining)]
private void VerifySetPropertyInternalArguments<T>(
  string propertyName, IEqualityComparer<T> comparer)
{
  Debug.Assert(
    VerifySetPropertyArguments,
    "Invalid operation.",
    "This method should only be called when the 'VerifySetPropertyArguments' " + 
    "property returns a value of true.");
  Debug.Assert(
    comparer != null, 
    "Argument null.", 
    "Argument 'comparer' should not be a null reference.");
  var type = GetType();
  var propertyType = typeof(T);
  PropertyInfo property = type.GetProperty(propertyName, propertyType);
  if (property == null)
  {
    throw new ArgumentException(
      string.Format(
        CultureInfo.InvariantCulture,
        "The argument does not represent the name of a property on this type with " +
        "the expected return type. One or more of the following values is wrong.\n\n" +
        "Type: {0}\nProperty name: {1}\nProperty type: {2}",
        type.FullName, propertyName, propertyType.FullName),
      "propertyName");
  }
  else
  {
    MethodBase expectedSetMethod = property.GetSetMethod();
    var frame = new StackFrame(3);
    MethodBase actualSetMethod = frame.GetMethod();
    if (actualSetMethod != expectedSetMethod)
    {
      throw new ArgumentException(
        string.Format(
          CultureInfo.InvariantCulture,
          "The argument does not match the name of the property being set.\n\n" +
          "Expected property set method: {0}\nActual property set method: {1}",
          expectedSetMethod, actualSetMethod),
        "propertyName");
      }
    }
  }
}

The first assert ensures the method is being called only when necessary and the second assert has been retained from Part III because there should always be a comparer. The key difference is that we now throw an ArgumentException when detecting incorrect usage. If the expected property cannot be found you’ll see the following exception details:

 

If the wrong property setter is being called you’ll see the following exception details:

 

You’ve probably noticed the MethodImplAttribute class on the methods above with the MethodImplOptions.NoInlining value. Even though the default behaviour is for the verification code to only run under the debugger, we can’t assume that will always be the case. This means we don’t know if the jitter has applied optimisations, such as method inlining, which could cause the verification code to produce false positives. Using the NoInlining value prevents a method from being inlined, ensuring that the verification code performs as expected.

The next issue to address is that the SetPropertyInternal method can call unknown code. In Part V we'll look at how this can occur, why it's a problem and how we can fix it.



Implementing Observable Objects – Part III
2009-01-28T23:00:00.001Z
In Part II we saw the introduction of the ObservableItem base class, which simplifies the property update mechanism by placing all of the boilerplate code in the SetProperty method. The problem with this approach is that it’s too easy to make a mistake with the property names, so now we’re going to reinforce the SetProperty method by asserting the relevant assumptions. These assumptions are:


  A property with the specified name exists on the type. 
  The invoked method is the property setter for the property with the specified name. 


To facilitate this we need to restructure the SetProperty method so that both overloads funnel through to the same method. I’ll explain why this is necessary in more detail later, but for now here’s the new structure:

protected void SetProperty<T>(string propertyName, ref T field, T value)
{
  SetPropertyInternal(propertyName, ref field, value, EqualityComparer<T>.Default);
}

protected void SetProperty<T>(
  string propertyName, ref T field, T value, IEqualityComparer<T> comparer)
{
  SetPropertyInternal(
    propertyName, 
    ref field, 
    value, 
    comparer == null ? EqualityComparer<T>.Default : comparer);
}

private void SetPropertyInternal<T>(
  string propertyName, ref T field, T value, IEqualityComparer<T> comparer)
{
  DebugVerifySetPropertyInternalArguments(propertyName, comparer);
  if (!comparer.Equals(field, value))
  {
    field = value;
    OnPropertyChanged(new PropertyChangedEventArgs(propertyName));
  }
}

Not a huge change as you can see. The implementation is essentially the same although there’s a new method – DebugVerifySetPropertyInternalArguments – called before the equality check. This is the method that contains the relevant asserts.

[Conditional("DEBUG")]
private void DebugVerifySetPropertyInternalArguments<T>(
  string propertyName, IEqualityComparer<T> comparer)
{
  Debug.Assert(
    comparer != null, 
    "Argument null.", 
    "Argument 'comparer' should not be a null reference.");
  var type = GetType();
  var propertyType = typeof(T);
  PropertyInfo property = type.GetProperty(propertyName, propertyType);
  if (property == null)
  {
    Debug.Fail(
      "Argument invalid.",
      string.Format(
        CultureInfo.InvariantCulture,
        "Argument 'propertyName' does not represent the name of a property on this " +
        "type with the expected return type. One or more of the following values " +
        "is wrong.\n\nType: {0}\nProperty name: {1}\nProperty type: {2}",
        type.FullName, propertyName, propertyType.FullName));
  }
  else
  {
    MethodBase expectedSetMethod = property.GetSetMethod();
    var frame = new StackFrame(3);
    MethodBase actualSetMethod = frame.GetMethod();
    Debug.Assert(
      actualSetMethod == expectedSetMethod,
      "Argument invalid.",
      string.Format(
        CultureInfo.InvariantCulture,
        "Argument 'propertyName' does not match the name of the property being " +
        "set.\n\nExpected property set method: {0}\nActual property set method: {1}",
        expectedSetMethod, actualSetMethod));
  }
}

The first assert verifies that we have a comparer, otherwise we have no way of knowing whether or not the value has changed. The second assert verifies that the type has a property with the correct name and return type. If you make a mistake like specifying a non-existent property name, then you’ll see the following message under the debugger:

 

The final assert verifies that once we have identified a property with the correct name and return type, the property’s set method matches the method being invoked. This is why we had to restructure the overloads, because the invoked method is retrieved from a StackFrame. Having all of the SetProperty overloads call SetPropertyInternal means we always know how many frames to skip to get to the property setter. If you make a mistake like specifying an existing property name in the wrong property setter, then you’ll see the following message under the debugger:

 

Both of these messages are extremely useful for quickly and accurately tracking down typos and copy/paste errors in debug builds.

The observant among you will no doubt have spotted that there are still a few issues. One of which is that the ObservableItem class is public and the SetProperty overloads are therefore part of its public API. Now it’s entirely possible for your data model assembly to be a private assembly, i.e. an assembly that isn’t intended or authorised to be used by third parties. When this isn’t the case however, we can’t rely on the use of asserts because third parties are unlikely to be using debug builds of your data model. Another worry is that we can conveniently ignore the overhead of using reflection and interrogating the call stack with the asserts because they’ll only execute in debug builds. We really don’t won’t to incur this overhead at such a low level in our data model for release builds. In Part IV we’ll look at an approach that provides the same level of diagnostic assistance as the asserts described here but without requiring access to a debug build of the data model and without unnecessarily penalising the release build performance.



Implementing Observable Objects – Part II
2009-01-27T23:00:00.001Z
In Part I we looked at a very straightforward implementation of the INotifyPropertyChanged interface to create an observable object. Unfortunately there aren’t many data models where one observable object with two properties will suffice J. This means you can find yourself repeating a lot of boilerplate code in each property setter. We can use the following base class to make implementing the property setters a little more trivial:

public abstract class ObservableItem : INotifyPropertyChanged
{
  protected ObservableItem()
    : base()
  {
  }

  public event PropertyChangedEventHandler PropertyChanged;

  protected virtual void OnPropertyChanged(PropertyChangedEventArgs e)
  {
    PropertyChangedEventHandler handler = PropertyChanged;
    if (handler != null)
    {
      handler(this, e);
    }
  }

  protected void SetProperty<T>(string propertyName, ref T field, T value)
  {
    SetProperty(propertyName, ref field, value, null);
  }

  protected void SetProperty<T>(
    string propertyName, ref T field, T value, IEqualityComparer<T> comparer)
  {
    if (comparer == null)
    {
      comparer = EqualityComparer<T>.Default;
    }
    if (!comparer.Equals(field, value))
    {
      field = value;
      OnPropertyChanged(new PropertyChangedEventArgs(propertyName));
    }
  }
}

The SetProperty method compares the current value in a property’s backing field with the new value and raises the PropertyChanged event if the value has changed. In order to update the property’s backing field we have to pass it by reference. For those of you that make use of the code analysis support in Visual Studio, you’ll notice that the SetProperty method actually violates the DoNotPassTypesByReference rule. I think this is a justifiable violation given that it improves the maintainability of you observable objects, so I always add the following suppression:

[SuppressMessage(
  "Microsoft.Design", 
  "CA1045:DoNotPassTypesByReference", 
  Justification = 
    "This method performs the common functionality required for setting a " + 
    "property, which includes raising events. To set the value of the property's " + 
    "backing field, the backing field must be passed by reference.", 
  MessageId = "1#")]

Now we can re-write the Person class as follows:

public class Person : ObservableItem
{
  private string m_firstName;
  private string m_lastName;

  public string FirstName
  {
    get { return m_firstName; }
    set { SetProperty("FirstName", ref m_firstName, value, StringComparer.Ordinal); }
  }

  public string LastName
  {
    get { return m_lastName; }
    set { SetProperty("LastName", ref m_lastName, value, StringComparer.Ordinal); }
  }
}

The property setters now contain just one line of code but we're not done yet. A weakness of this approach is that with an unfortunate typo – an occupational hazard in software development J –or with some copy/paste abuse we can end up supplying the wrong property name to the SetProperty method. In Part III we’ll look at making the SetProperty method more robust to these mistakes.



Implementing Observable Objects – Part I
2009-01-26T23:00:00.001Z
Whether you writing a Windows Forms or WPF application there’s a good chance you'll want to leverage the support both platforms have for data binding by constructing a data model that can be observed by the views in you application. One way to achieve this in .NET is by implementing the INotifyPropertyChanged interface, which is supported by the data binding mechanisms of Windows Forms and WPF. Here’s a very simple example:
  public class Person : INotifyPropertyChanged
{
  private string m_firstName;
  private string m_lastName;

  public Person() 
    : base()
  {
  }

  public event PropertyChangedEventHandler PropertyChanged;

  public string FirstName
  {
    get { return m_firstName; }
    set
    {
      if (!string.Equals(m_firstName, value, StringComparison.Ordinal))
      {
        m_firstName = value;
        OnPropertyChanged(new PropertyChangedEventArgs("FirstName"));
      }
    }
  }

  public string LastName
  {
    get { return m_lastName; }
    set
    {
      if (!string.Equals(m_lastName, value, StringComparison.Ordinal))
      {
        m_lastName = value;
        OnPropertyChanged(new PropertyChangedEventArgs("LastName"));
      }
    }
  }

  protected virtual void OnPropertyChanged(PropertyChangedEventArgs e)
  {
    PropertyChangedEventHandler handler = PropertyChanged;
    if (handler != null)
    {
      handler(this, e);
    }
  }
}

That’s all there is to it. Views that data bind to the Person object will automatically update when either the FirstName or LastName properties are changed. You can download sample WPF and Windows Forms applications demonstrating this using the link at the bottom of this post. Both applications are very simple – they contain a list control that is data bound to a collection of Person objects and two text boxes that are data bound to the FirstName and LastName properties of the selected item in the list control. The screenshot below is from the WPF application.

 

Now, there’s nothing terribly wrong with the Person object in this example but you’ll probably have more than two properties on your data model objects and it can become cumbersome writing similar code for each property setter. In Part II we’ll look at reducing this burden.
  


Unit Testing Expected Exceptions
2009-01-23T23:00:00.000Z
Both NUnit and Visual Studio use an attribute to specify that an exception is expected during execution of a test. The problem with this approach is that it could hide bugs when the expected exception is thrown by a method that we did not expect to throw. In other words, even though the test passes we’re not testing what we think we’re testing. What we really want is a way of providing a scope for the exception that’s more granular than the scope of the entire test. Here are a few options for achieving this:
     Use xUnit.net, which has a generic Throws method on its Assert class to specify that a provided delegate should throw an exception. 
    Use NUnit 2.5, which is currently still in beta. This brings NUnit inline with xUnit.net by adding a similar generic Throws method to its Assert class, plus it extends the constraint model with a Throws constraint. 
    Continue using NUnit and Visual Studio as they exist today, but include your own generic Throws method in a support assembly that all your tests can use. 
 
  If you have to go for the third option, here’s what I use for unit tests in Visual Studio:
  public static class ExceptionAssert
{
  public static TException Throws<TException>(Action action)
    where TException : Exception
  {
    Assert.IsNotNull(action, "Argument 'action' cannot be a null reference.");
    Exception thrownException = null;
    try
    {
      action();
    }
    catch (Exception ex)
    {
      thrownException = ex;
    }
    var expectedExceptionType = typeof(TException);
    Assert.IsNotNull(
      thrownException,
      "Expected an exception of type '{0}', but no exception was thrown.",
      expectedExceptionType.FullName);
    var actualExceptionType = thrownException.GetType();
    Assert.AreSame(
      expectedExceptionType,
      actualExceptionType,
      "The thrown exception is not an instance of the expected exception type.");
    return (TException)thrownException;
}

Adapting this to NUnit should be straightforward as all you have to do is change the asserts to their NUnit equivalents. Here’s an example of a test that uses this assert:

[TestMethod]
public void CopyConstructorWithExceptionForNullPrototype()
{
  ArgumentNullException ex = ExceptionAssert.Throws<ArgumentNullException>(
    () => new MyClass(null));
  Assert.AreEqual(
    "prototype", 
    ex.ParamName, 
    "The exception identifies the wrong parameter name.");
}

Returning the exception from the assert also allows us to verify whether or not the relevant properties have been set for the exception.
  


Beware of Unchecked Integer Arithmetic
2009-01-22T23:00:00.001Z
C# provides the checked and unchecked keywords to enable and disable overflow checking for integer arithmetic. It might surprise you to know that Visual Studio C# projects disable overflow checking by default. Consider the following example:

var a = int.MaxValue;
Console.WriteLine(++a);

With the default project settings this code will output –2147483648 instead of throwing an OverflowException. Personally I think overflow checking should be enabled by default since overflow is rarely intentional and when it is, well that’s what the unchecked keyword is for. Fortunately changing the default behaviour for Visual Studio C# projects is straightforward. Open the project properties page, select the Build tab and click the Advanced… button.



Check the Check for arithmetic overflow/underflow check box in the resulting dialog as shown above. I’d recommend doing this for all of your build configurations.



Exposing Collections Using a More Restricted Interface
2009-01-21T23:00:00.001Z
It’s quite reasonable to want to expose a collection as a property where the type of the property is a base type of the backing field. For example, the backing field for a collection property could be declared as List<string> but the property itself could be declared as IEnumerable<string>. This is useful when you need to modify the collection from within the type but don’t want clients to have the same freedom. You could implement this as follows:

public class MyClass
{
  private readonly List<string> m_items = new List<string>();

  public IEnumerable<string> Items
  {
    get { return m_items; }
  }
}

Simple right? Unfortunately not. The problem here is that we’re still returning an instance of List<string> even though we only expose it as IEnumerable<string>. Callers can still cast the instance we returned to a more specialised type, which means they can modify the collection and generally wreak havoc. One way to address this is to return a proper read-only instance, such as ReadOnlyCollection<string>.

public class MyClass
{
  private readonly List<string> m_items = new List<string>();
  private readonly ReadOnlyCollection<string> m_itemsReadOnly;

  public MyClass()
    : base()
  {
    m_itemsReadOnly = m_items.AsReadOnly();
  }

  public IEnumerable<string> Items
  {
    get { return m_itemsReadOnly; }
  }
}

Now if a caller casts the returned instance to a more specialised type, such as ICollection<string>, any attempt to modify the collection will throw a NotSupportedException because the instance we returned is read-only. But why do we need a separate backing field for the read-only collection? Well the Framework Design Guidelines states that properties should not return a different result each time they’re invoked. For reference types this means we should return the same instance. This makes sense when we consider that properties are generally expected to behave like fields but with some additional lightweight logic thrown in to the mix. In other words, we’d expect both of the following lines to evaluate to true.

m_value == m_value;       // Field equal to itself?
item.Value == item.Value; // Property equal to itself?

This means we can’t use the AsReadOnly method in the property because it will return a different instance each time. We have to use a separate backing field for the read-only collection to achieve the expected behaviour for a property. We also don’t have to worry about updating this backing field when the collection changes because the AsReadOnly method returns a wrapper around the original collection. Another approach I’ve seen is to use an iterator as shown below.

public class MyClass
{
  private readonly List<string> m_items = new List<string>();

  public IEnumerable<string> Items
  {
    get
    {
      foreach (string item in m_items)
      {
        yield return item;
      }
    }
  }
}

This works because the iterator will generate its own implementation of IEnumerable<string> which is completely independent of the implementation provided by List<string>. This means a caller cannot cast the returned instance to a more specialised type.  Unfortunately it will also return a different instance every time we access the property, which as we’ve already seen is not how properties should behave. So why not make it a method then? Well if the member represents a logical attribute of the type then it really should be a property. The Items member seems to fit the bill, so a property is the right choice.



RIP Debug.WriteLine
2009-01-20T23:00:00.001Z
Not all developers using Visual Studio are aware of the fact that you can use breakpoints to write to the debug window. This saves you from having calls to Debug.WriteLine littered throughout your code, which you may not want to check-in. The reason for not checking-in Debug.WriteLine calls is that it can clutter up the debug window for everyone working on the same source, making it hard for developers to pick out specific debug information they’ve added. Using a breakpoint allows you to keep the debug information local to your machine.

To make a breakpoint that writes to the debug window, create a breakpoint as you normally would and right-click on it to bring up its context menu. Then select the When Hit... menu item as shown below.



Check the Print a message: check box in the When Breakpoint Is Hit dialog and enter the text you want written to the debug window.  In the screenshot below I’ve chosen to output the fully qualified method name followed by the value of the PropertyName property.



Make sure the Continue execution check box is checked to prevent the debugger from stopping at the breakpoint.

You can also combine multiple items in the breakpoint context menu. For example, you can select the Condition... menu item in addition to the When Hit... menu item to write to the debug window only when a condition is either true or has changed.



All of this without having to make a single call to Debug.WriteLine. May it rest in piece J.



Operator Overloads vs. Methods
2009-01-19T23:00:00.001Z
It’s common practice for API designers providing operator overloads to follow the advice given in the Framework Design Guidelinesand also provide methods with friendly names for the same operations. For example, the designers of the Vector3D structure provided a Multiply method and a Multiply operator to support multiplying a vector by a scalar. Why do they do this? Well, you can’t guarantee that all .NET programming languages will support operator overloading because it is not part of the Common Language Specification. If you use C#, which does support operator overloading, then you’re free to choose either the operators or the methods as there’s no difference between them, right? Well a problem I encountered recently made me stop and think about operator overloads, and how it can be difficult to keep track of the number of temporary objects being created. Consider the following snippet:

private readonly List<Point3D> m_points;
private readonly List<Vector3D> m_velocities;

public void UpdatePoints(double variance, double ellapsedTime)
{
  Debug.Assert(
    m_points.Count == m_velocities.Count, 
    "Invalid collections.", 
    "Fields 'm_points' and 'm_velocities' should have equal counts.");
  for (int i = 0; i < m_points.Count; i++)
  {
    m_points[i] -= m_velocities[i] * variance * ellapsedTime;
  }
}

How many Vector3D objects are being created each time through the loop? Let's re-write the snippet to emphasise the temporary objects.

private readonly List<Point3D> m_points;
private readonly List<Vector3D> m_velocities;

public void UpdatePoints(double variance, double ellapsedTime)
{
  Debug.Assert(
    m_points.Count == m_velocities.Count, 
    "Invalid collections.", 
    "Fields 'm_points' and 'm_velocities' should have equal counts.");
  for (int i = 0; i < m_points.Count; i++)
  {
    Vector3D tmp1 = vectors[i] * variance;
    Vector3D tmp2 = tmp1 * ellapsedTime;
    m_points[i] -= tmp2;
  }
}

This makes it much easier to spot that two temporary Vector3D objects are being created for the vector-scalar multiplications, i.e. one of them is unnecessary because we can combine the scalar values. Compare this with the original snippet re-written again to use the Multiply method instead of the operator overload.

private readonly List<Point3D> m_points;
private readonly List<Vector3D> m_velocities;

public void UpdatePoints(double variance, double ellapsedTime)
{
  Debug.Assert(
    m_points.Count == m_velocities.Count, 
    "Invalid collections.", 
    "Fields 'm_points' and 'm_velocities' should have equal counts.");
  for (int i = 0; i < m_points.Count; i++)
  {
    m_points[i] -= Vector3D.Multiply(
      Vector3D.Multiply(m_velocities[i], variance), ellapsedTime);
  }
}

I think it's now obvious that we're performing two vector-scalar multiplications. In fact, had I used the Multiply method initially I'm certain I would have automatically used only one Multiply call as follows:

private readonly List<Point3D> m_points;
private readonly List<Vector3D> m_velocities;

public void UpdatePoints(double variance, double ellapsedTime)
{
  Debug.Assert(
    m_points.Count == m_velocities.Count, 
    "Invalid collections.", 
    "Fields 'm_points' and 'm_velocities' should have equal counts.");
  for (int i = 0; i < m_points.Count; i++)
  {
    m_points[i] -= Vector3D.Multiply(m_velocities[i], variance * ellapsedTime);
  }
}

But is creating a few too many temporary Vector3D objects that bad? Well in this scenario it depends on how many loops you perform and, even more importantly, what platform you're targeting. The impact for code running on desktops/servers will probably be negligible but I was certainly surprised by the difference these changes made on mobile/embedded devices. As a result I've begun to favour the clarity of methods over the terseness of operator overloads. There’s no guarantee that this will always provide any noticeable performance improvements but in my opinion the methods are closer to the pit of success than the operator overloads. Note that the standard performance advice still applies, which is measure, measure, measure J.



Better Freezing with Extension Methods
2009-01-16T23:00:00.001Z
You can improve the performance of Freezable objects in WPF by calling the Freeze method. Frozen objects no longer need to be tracked by WPF and the thread affinity associated with WPF objects no longer applies. The documentation mentions a few cases where a Freezable object cannot be frozen:


  It has animated or data bound properties.
  It has properties that are set by a dynamic resource.
  It contains Freezable sub-objects that cannot be frozen.


If the Freezable object cannot be frozen, the Freeze method will throw an InvalidOperationException. Unless you’re absolutely certain that the Freeze method will always succeed, you should invoke it as follows:

if (myFreezable.CanFreeze)
{
  myFreezable.Freeze();
}

Unfortunately the Freezable object API does not provide a TryFreeze method for scenarios when you don't care if the object can be frozen or not, i.e. you just want to freeze it whenever possible. You don’t really want the above code littered throughout your projects and a static helper method, while certainly better, may not be easily discovered even if it lives in a commonly imported namespace. I prefer to use the following extension method:

internal static class FreezableExtensionMethods
{
  public static void TryFreeze(this Freezable freezable)
  {
    DebugVerifyFreezable(freezable);
    if (freezable.CanFreeze)
    {
      freezable.Freeze();
    }
  }

  [Conditional("DEBUG")]
  private static void DebugVerifyFreezable(Freezable freezable)
  {
    Debug.Assert(
      freezable != null, 
      "Argument null.", 
      "Argument 'freezable' should not be null.");
  }
}

Using extension methods in this way improves the discoverability of common operations on types you don't own, assuming of course that they live in a frequently imported namespace. Note that I emphasised common in the previous sentence because extension methods should not be used frivolously. The Framework Design Guidelinesprovides good advice about when to use extension methods. This advice is primarily intended for public APIs but in my opinion is equally valid for internal APIs.



Auto-Implemented Properties and Expressing Intent
2009-01-14T23:36:00.001Z
Auto-implemented properties provide a convenient way to quickly declare properties. This assumes of course that you don't need to run any logic, such as validation, in your property and that it is not read-only. Hang on, that last bit's wrong isn’t it? You can declare a read-only auto-implemented property as follows:

public bool IsReadOnly { get; private set; }

I see this quite a lot but I've got to be honest and say I'm not a big fan of using auto-implemented properties in this way. Why? Well it's only pretending to be a read-only property to the outside world. Internally the property could be modified after construction. If the intention is for the property to only be set during construction then this approach doesn’t fully reflect the intent. I’d always recommend writing code that most accurately expresses your intent, which in this case means a good old fashioned property with a read-only backing field.

private readonly bool m_isReadOnly;

public bool IsReadOnly
{
  get { return m_isReadOnly; }
}

Implementing the property this way means any attempt to set the backing field after construction will be detected by the compiler. The more bugs the compiler can detect the better J.



So Where's the Code?
2008-12-22T20:37:00.008Z
The code is coming J, but this blog won't officially start until 2009.