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

Specialize relative leafref types during instantiation

XMLWordPrintable

    • Icon: Improvement Improvement
    • Resolution: Done
    • Icon: Medium Medium
    • 7.0.3
    • None
    • Binding codegen
    • None

      MDSAL-182 uncovers a case where a grouping definition cannot fully resolve the type of a leaf. The solution is to fall back to java.lang.Object.

      This solution needs to be further improved, as in some cases we can determine what the type is, for example in:

          grouping foo {
        leaf foo {
            // java.lang.Object
            type leafref {
                path "../../bar";
            }
        }
    }

    container one {
        leaf bar {
            type string;
        }
        // leaf foo is java.lang.String
        uses foo;
    }

    container two {
        leaf bar {
            type uint16;
        }
        // leaf foo is java.lang.Integer
        uses foo;
    }

      Both One and Two can specialize their return type to either String or Integer and have their Builders require the proper type. This obviously needs to work with groupings, too:

          grouping foo {
        leaf foo {
            type leafref {
                path "../../bar";
            }
        }
    }

    grouping one {
        leaf bar {
            type string;
        }
        uses foo;
    }

    container cont {
        uses one;
    }

      This also means grouping copy builders need to take specializations into account and perform checkArgument() to determine if the source grouping actually has a compatible specialization.

            ilyaigushev Ilya Igushev
            rovarga Robert Varga
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: