Availability behavior is partly duplicated between the Availability class and the tables that own them.

[efronbs]

Part of the physical table's interface exposes methods for querying the table's availability. Basic physical tables often defer these queries to their underlying Availability objects. However, there are also times when the physical table's underlying Availability is directly accessed and used. This occurs when creating ConstrainedTable objects. ConstrainedTable freezes its availability by directly accessing its physical table's underlying availability and storing final copies of the results of queries to the Availability object.

This behavior makes creating decorators for physical tables somewhat unintuitive. The decorator wants to be able to defer availability queries to the underlying physical table and simply annotate the results. However, since the physical table's Availability object can also be extracted and queried, the table decorator class also needs an Availability decorator to apply it's transforms to the target physical table's Availability object. Because of this we now require two decorator classes that each have almost duplicate functionality but are unable to defer to each other's implementation, because it opens up risk of incorrect behavior (i.e. Availability deferring to the table decorator, even though it should be based on the target table's frozen Availability).