Changing access nodes

Usually, a property and value handles refers the same access node between opening and closing it. In some cases, however, property and value handles are reopened implicitly and the access node may change. This happens, e.g. when referring to properties in weak-typed collections. Patient ( Person ) as well as Employee ( Person ) may have got an address , which is not defined in Person , but in Patient and Employee , instead. One possible reason is, that address specifications differ slightly.

When iterating through the collection, the type of the selected instance may change from Employee to Patient . In this case, a value handle referring to the subordinated address attribute, would become inaccessible. In order to avoid this side effect, you could call value() each time when accessing the data rather than creating a subordinated property handle for the internal access node.

This is, however, not only rather inefficient, but may also cause a number of other problems. Since property and value handles may have set event handlers or filters, those get lost, when property() or value() returns a different access node in the handle. When creating a subordinated property handle, instead, handlers and filters are automatically copied to the new property node.