October 8th, 2025
0 reactions

Windows Runtime API design principles around read-write properties: Idempotence and self-assignment

Objects in the Windows Runtime can have properties, and those properties could be read-only or read-write. For read-write properties, there are a few general principles. Today we’re going to look at this one:

  • Setting a property to its current value is legal and has no effect.¹

For example:

// C#
o.Color = o.Color;

// C++/WinRT
o.Color(o.Color());

We are setting a property’s value to the value it already has.

Now, this may look like a pointless thing to write on its own, but it could fall out of other code.

// C#
o.Color = EnsureSufficientContrast(o.Color, m_backgroundColor);

// C++/WinRT
o.Color(EnsureSufficientContrast(o.Color(), m_backgroundColor);

The hypothetical Ensure­Sufficient­Contrast function returns a foreground color that provides sufficient contrast against a background color. It’s possible that the existing foreground color already provides sufficient contrast, in which case the original color is returned unaltered.

This principle seems obvious, but it comes with corollaries.

  • Corollary: Setting a property twice to the same value has no effect.

Setting the property multiple times is the same as setting it once.

I remember many years ago I was looking at a customer program, and they had a property called Print. Setting it to True caused a document to print. I don’t mean that it resulted in a printout happening when you submitted the document. I mean it printed the document at the moment you set the Print property. If you wanted to print two copies, you would do

document.Print = True ' Print it
document.Print = True ' Print it again

This was definitely a violation of the idempotence principle. As well as a violation of other principles like “What were you thinking?”

Next time, I’ll look another simple corollary to the idempotence principle that people often are tempted to violate.

¹ By “no effect” here, I mean no functional effect. Clearly the code runs more slowly because you’re performing a redundant operation, and there might be follow-on calculations that occur when the property is set. But the point is that the correctness of the program is not affected by the redundant write to the property.

Topics
Code

Author

Raymond has been involved in the evolution of Windows for more than 30 years. In 2003, he began a Web site known as The Old New Thing which has grown in popularity far beyond his wildest imagination, a development which still gives him the heebie-jeebies. The Web site spawned a book, coincidentally also titled The Old New Thing (Addison Wesley 2007). He occasionally appears on the Windows Dev Docs Twitter account to tell stories which convey no useful information.

1 comment

Sort by :
  • Yuri Khan 22 seconds ago

    I think I have seen some VBX components that showed their About boxes on some property assignment. Probably because property assignment is pretty much all you can do to a component right from the form designer.