I have been spending more time looking into WPF recently. One thing that I am discovering is that, underneath all of the new and fancy terms like "Dependency Properties", many of the concepts in WPF are just a rehash of similar concepts from Windows Forms, with adjustments made for lessons learned from previous technologies. Dependency Properties are a somewhat complex concept, but one particular aspect of them, Attached Dependency Properties, are almost a direct replacement for the Extender Provider technology from WinForms. Extender providers (components which implement IExtenderProvider) allowed designers to "add" properties to other components on a design surface (such as a form). Of course, you can't actually add properties to an instance; instead, the extender provider would store the property values associated with each instance. Attached dependency properties are similar; they allow objects to "attach" properties onto other objects.
There is at least one difference between the two technologies. Properties added by an extender provider applied to the whole design surface to which the component was added (although the specific components to which properties were added could be filtered); attached dependency properties allow more fine-grained control by only adding properties to elements which exist underneath the adding element in the UI hierarchy.
For example, in WinForms, the Control class from which all WinForms controls are derived has the properties Left and Top. These properties specify where on the parent control these controls are placed. However, the control itself will almost never use these properties; it is the parent control which uses them to place the control within its container. So these properties don't really belong on the control to which they apply; but that was the only consistent way to implement that requirement in WinForms.
In WPF, these properties exist as attached dependency properties on the Canvas class. So any UI element which is added to a Canvas "gains" these additional properties, which can be set on the element in XAML ("Canvas.Left = '30'"). But it is the Canvas itself which actually holds these values. All UI elements do not have to implement these properties themselves in order to be used on a Canvas (and in fact, in many cases these properties wouldn't make sense, such as if the element were added to a StackPanel instead).
Another way to think of attached dependency properties is by thinking about roles. You could describe a UI element placed on a Canvas as taking on the role of an "absolutely positioned UI element". This role is not part of the element's class hierarchy; being absolutely positioned is not an inherent part of its existence. But as soon as it is placed on the Canvas, it takes on that role, and there is additional data (properties) which relate to its existence in that role that must be "attached" to it. Attached dependency properties allow the Canvas to fit the UI element into that role, without the element itself ever needing to know about it (i.e. without those properties having to exist in the type hierarchy of the element itself).
Since I have been interested lately in the concept of objects taking on roles, rather than simply existing in a static type hierarchy, I am curious as to how far this concept of attached properties and roles could be taken; something I will be exploring in the near future. Does anyone have any immediate thoughts?