https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/YANGTOOLS-948 yangtools <p>We currently have seven distinct implementations of this method, which really come down to following behaviors:</p> <ol> <li>delegates</li> <li>throws UnsupportedOperationException</li> <li>guards path argument for a type before returning a constant</li> <li>looks up in a pre-computed map</li> <li>perfoms a cached lookup</li> </ol> <p>Options 3-5 are only accessible through SchemaAwareApplyOperation, hence we should be to make the method bimorphic and delegate internally to a utility class.</p> YANGTOOLS-948

Encapsulate ModificationApplyOperation.getChild() overrides

Improvement Medium Resolved Won't Do Unassigned Robert Varga Thu, 31 Jan 2019 14:30:17 +0000 Wed, 13 Feb 2019 18:33:20 +0000 Wed, 13 Feb 2019 18:33:20 +0000 data-impl 0 1 <p>The key problem with this is that 'UnsupportedOperationException' is used by leaf nodes, hence moving this to a field value would increase our memory overhead significantly. In-memory layout of SchemaAwareApplyOperation needs to be looked at to evaluate the impact. Maybe that behavior can be set as the default, with others overriding it?</p> <p>Item 3 is used by invisible nodes (lists), but LeafSets are value-based and hence they our outside of the class hierarchy of MapNodes.</p> <p>Item 4 and 5 look very much alike, so could probably be unified at the cost of paying a volatile deref in ChoiceModificationStrategy by using a completely pre-computed mapping. The cost of doing this is moving the backing field and acquire/store into a common subclass.</p> <p>I don't think the added indirection is worth it, unless we can we end up having a cozy place in SchemaAwareApplyOperation on which we can piggy-back this behavior.</p> Relates YANGTOOLS-951 Development Epic Link YANGTOOLS-940 Rank 0|i03mgn: