[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:
Blocks
blocks MDSAL-746 Improve BitsTypeObject storage Confirmed

 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.


Generated at Wed Feb 07 20:10:54 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.