robshakir
commented
4 years ago There's a trade-off here, that we discussed in the original ygot design.
Particularly, for re-use:
- ✅ Minimises the generated code.
- ✅ Allows handling common containers using generic handling methods, rather than needing reflection.
- ❌ Involves the developer understanding more about the YANG structure, rather than just using the generated code.
- ❌ Can result in changes in the generated types later down the line (e.g., if I augment a particular container such that it is no longer identical then the type must change), which can cause code churn.
- ❌ Adds some complexity of potentially having common code that maps to >1 different schema path, which have some schema differences (e.g., parent node context etc.).
We decided at the time that the advantages that came from having common code didn't outweigh the complexities and lifecycle management challenges that it seemed to come with. For different use cases, this might be different.
I'd be open to reviewing a design for this -- and subsequent code changes -- but we should have a solid story as to how we expect to name things, how we handle stability, and how we handle the changes that are needed to ytypes to handle this before starting to make commits. If this is something that you're interested in pursuing, please let me know -- and Wen and I can likely help discuss.
mbalachandar
wenovus
Hi
My question is about reusing/referring the same the generated ygot structure in the other places of the generated code.
For example, I have a grouping called "G" which contains a container "X" - which is augmented inside the different containers A ,B, and C. Here in this case, 3 different YGOT structure types for the container "X" is generated, that is for A, B, and C.
Is there any option (or) can we have the option -- to generate the code to keep the same ygot structure type of container "X" in all the places of A, B and C, instead of generating different types of ygot structure for container "X" w.r.t A,B, and C.
Thanks Balachandar