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/MDSAL-198 mdsal <p>It would be "nice" (this is an Enhancement, not a Bug) if an Augmentable DataObject would have an alternative sugar shortcut new addAugmentation method variant which does not require the first (java.lang.Class&lt;? extends Augmentation&lt;...&gt;&gt; augmentationType but only the second Augmentation&lt;...&gt; augmentation argument.</p> <p>This would just shorten the typical and often found code which IMHO is a little a silly, where the interface of an augmentation has to be specified together with creating ("can't it figure this out by itself??" - kind of thing).</p> <p>Operating System: All<br/> Platform: All<br/> URL: <a href="https://git.opendaylight.org/gerrit/#/c/45742/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/45742/</a></p> MDSAL-198

Augmentable's Builder addAugmentation variant without first class argument

Improvement Lowest Resolved Done Robert Varga Michael Vorburger Fri, 16 Sep 2016 16:12:25 +0000 Sun, 19 Jul 2020 10:20:42 +0000 Tue, 21 Apr 2020 07:47:51 +0000 6.0.0 Binding codegen 0 2 <p>If only Augmentation had a getImplementedInterface() method just like DataContainer does, then it would seem totally feasible to generate convenience shortcut methods like this in *Builder classes:</p> <p> public *Builder addAugmentation(Augmentation&lt;...&gt; augmentation) {<br/> this.addAugmentation(augmentation.getImplementedInterface(), augmentation);</p> <p>but of course Augmentation does not have getImplementedInterface() - yet. I could see following possible solutions:</p> <p>1. In reality, one can see that all gen. YANG augmentations interfaces always extend both DataObject and Augmentation. So initially I was tempted to propose that Augmentation simply extend DataObject or DataContainer .. but rovarga when asked on IRC if it "would it be conceivable to make Augmentation extend DataContainer" on IRC clarified that "not sure, probably that's not what we want to do... pretty sure it's not &#8211; due to InstanceIdentifier type safety &#8211; cannot start with an Augmentation".</p> <p>2. We could attempt to factor out the getImplementedInterface() method currently declared on DataContainer into some new interface, and have both DataContainer and Augmentation extend that. I've tried that, and it lead to a frightening encounter with Java Generics Hell, so unless someone smarter sees a way of doing this that I missed, I don't think this is feasible (because getImplementedInterface() in DataContainer returns, rightfully Class&lt;? extends DataContainer&gt;, and Augmentation's getImplementedInterface() would have to return Class&lt;? extends Augmentation&gt; but that will, correctly, lead to type conflict on YANG augmentations interfaces always extend both DataObject and Augmentation.</p> <p>3. Just let Augmentation have its own getImplementedAugmentationInterface() method, LIKE DataContainer, but without any code sharing and inheritance (that's probably never needed; because the "clients" using this always know whether they're dealing with an Augmentation or a DataContainer)</p> <p><a href="https://git.opendaylight.org/gerrit/#/c/45742/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/45742/</a> proposes implementation of approach 3.</p> <p>Hi</p> <p>is this still in progress? Please update. Many thanks.</p> Issue split MDSAL-575 Development External References <a href="https://git.opendaylight.org/gerrit/#/c/45742/">https://git.opendaylight.org/gerrit/#/c/45742/</a> External issue ID 6733 External issue URL Rank 0|i02wx3: