- /*
- * This is a bit tricky. DataObject addressing does not take into account choice/case statements, and hence
- * given:
- *
- * container foo {
- * choice bar {
- * leaf baz;
- * }
- * }
- *
- * we will see {@code Baz extends ChildOf<Foo>}, which is how the users would address it in InstanceIdentifier
- * terms. The implicit assumption being made is that {@code Baz} identifies a particular instantiation and hence
- * provides unambiguous reference to an effective schema statement.
- *
- * <p>
- * Unfortunately this does not quite work with groupings, as their generation has changed: we do not have
- * interfaces that would capture grouping instantiations, hence we do not have a proper addressing point and
- * users need to specify the interfaces generated in the grouping's definition. These can be very much
- * ambiguous, as a {@code grouping} can be used in multiple modules independently within an {@code augment}
- * targeting {@code choice}, as each instantiation is guaranteed to have a unique namespace -- but we do not
- * have the appropriate instantiations of those nodes.
- *
- * <p>
- * To address this issue we have a two-class lookup mechanism, which relies on the interface generated for
- * the {@code case} statement to act as the namespace anchor bridging the nodes inside the grouping to the
- * namespace in which they are instantiated.
- *
- * <p>
- * Furthermore downstream code relies on historical mechanics, which would guess what the instantiation is,
- * silently assuming the ambiguity is theoretical and does not occur in practice.
- *
- * <p>
- * This leads to three classes of addressing, in order descending performance requirements.
- * <ul>
- * <li>Direct DataObject, where we name an exact child</li>
- * <li>Case DataObject + Grouping DataObject</li>
- * <li>Grouping DataObject, which is ambiguous</li>
- * </ul>
- *
- * {@code byCaseChildClass} supports direct DataObject mapping and contains only unambiguous children, while
- * {@code byClass} supports indirect mapping and contains {@code case} sub-statements.
- *
- * ambiguousByCaseChildClass contains ambiguous mappings, for which we end up issuing warnings. We track each
- * ambiguous reference and issue warnings when they are encountered.
- */
- private final ImmutableMap<Class<?>, DataContainerCodecPrototype<?>> byClass;
- private final ImmutableMap<Class<?>, DataContainerCodecPrototype<?>> byCaseChildClass;