Details
-
Improvement
-
Status: Confirmed
-
Medium
-
Resolution: Unresolved
-
None
-
None
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.
Attachments
Issue Links
- blocks
-
MDSAL-746 Improve BitsTypeObject storage
-
- Confirmed
-
Gerrit Reviews
| # | Subject | Branch | Project | Status | CR | V |
|---|---|---|---|---|---|---|
| 101978,41 | WIP: Add binding.model.api.Archetype | master | mdsal | Status: NEW | 0 | -1 |
| 109392,7 | WIP: Remove Generated{Type,TransferObect} | master | mdsal | Status: NEW | 0 | -1 |
| 109393,9 | WIP: update mdsal-binding-generator | master | mdsal | Status: NEW | 0 | -1 |