[MDSAL-764] Refactor binding-model-api Created: 06/Aug/22 Updated: 10/Nov/22 |
|
| Status: | Confirmed |
| Project: | mdsal |
| Component/s: | Binding codegen, Binding Spec |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Medium |
| Reporter: | Robert Varga | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | pt | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Description |
|
mdsal-binding-model-api is overly generic. It originally supported two code generators, but one of them is gone and will never return. mdsal-binding-java-api-generator makes a ton of assumptions and reverse engineering of the generated model to distill information from the generic class model. We are searching for Foo in 'implements Augmentation<Foo>' and 'implements Identifier<Foo>'. This stems from the baseline objects known to mdsal-binding-model-api is Type (i.e. a Java type reference), GeneratedType (i.e. something we need to generate), GeneratedTransferObject (when its a class with properties), spiced up with isTypedef()/isUnion() property. Considering that mdsal-binding-model-api is an interface between YANG and its projection to Java, the coupling between mdsal-binding-generator and mdsal-binding-java-api-generator and the binding specification needs to be firmed up. This means making sure there is a yang-binding projection into GeneratedType class hierarchy, such that GeneratedType permits only its specializations – for example BuilderType, OpaqueType, ValueType, etc. Generator dispatch in java-api-generator then should use instanceof checks coupled with GeneratedType being sealed in an if/else cascade to select the appropriate template. |