[MDSAL-305] Parameters sequence of generated constructor for bits type leaf should be same as the sequence of its bit fields defined in its yang file Created: 31/Jan/18 Updated: 23/Feb/18 Resolved: 23/Feb/18 |
|
| Status: | Resolved |
| Project: | mdsal |
| Component/s: | Binding V2 codegen |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Medium |
| Reporter: | Kangqian Yin | Assignee: | Unassigned |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
Now the parameters sequence of generated constructor for bits type leaf is the alphabetic sequence of names of its bit fields defined in its yang file. Such alphabetic sequence comes from the sort operation on all properties in ClassTemplate.xtend in v1 binding generator. This is not natual and if application developper doesn't carefully take a look at the generated constructor, they will construct such leaf node in the sequence of bit fields defined in the yang file. And such misuse won't be reported by the Java compiler. Can we eliminate the sort operation on all properties in ClassTemplate.xtend and let the parameters of all generated constructors appear in their natural order? |
| Comments |
| Comment by Robert Varga [ 31/Jan/18 ] |
|
We cannot change this in Binding V1 without breaking existing users. Binding V2 is fair game. One question though: what is 'natural order'? Is this the order of increasing values or the order in which bits are defined? I suspect the former, but that detail needs to be clearly defined. |
| Comment by Kangqian Yin [ 31/Jan/18 ] |
|
I don't think so. I think the order in which bits are defined is more natural than sorted order of alphabetic names or digital positions. The order in which bits are defined won't change when binding generator is replaced or user appends new bit to the bits leaf. And the sorted order of alphabetic names may change on these two cases. However, if user inserts new bit in the middle of defined bit fields, all construction codes must be rewritten due to the natural order changes. In Scala, we can use pass-by-name paramenters to write codes immune to all these changes. But in Java, it seems no pass-by-name parementers feature until Java 9. Maybe in Java 10, we can enjoy this feature. |
| Comment by Robert Varga [ 23/Feb/18 ] |
|
So we cannot do this in V2. If ever Scala bindings materialize they can implement this. |