Uploaded image for project: 'mdsal'
  1. mdsal
  2. MDSAL-764

Refactor binding-model-api

    XMLWordPrintable

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

          # Subject Branch Project Status CR V

          Activity

            People

              Unassigned Unassigned
              rovarga Robert Varga
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated: