-
Notifications
You must be signed in to change notification settings - Fork 440
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature: Convert while preserving the order of fields in objects #903
Comments
Order of list elements is always preserved. Do you mean the order of object fields? |
Yes, I meant preserving the order of object fields. Currently, they seem to be sorted in alphabetical order. |
There are some existing issues about that (#407, probably something on go-jsonnet side as well...). There are some good reasons not to do it (it shouldn't matter, JSON objects are unordered), but it could be a usability win. So, if someone can propose a good, coherent solution I'll be happy to help make it happen. It's not exactly clear how to handle this in all cases. There were some discussions in the mailing list about that as well. Closing this for now and re-opening the original issue (where we have more context). |
My 2c is that not sorting the keys would also interfere with content hashing use-case e.g. doing |
@ilya-kolpakov Yes, that is correct. We certainly want to keep backwards compatibility w.r.t. how objects are manifested. So probably some additional hidden parameter on an object would be necessary to have fields manifested in non-alphabetical order. |
Hi @sbarzowski is there any update on this? |
@arpitjasa-db Not really. You can take a look at the mailing list for the related discussion. If someone can come up with an acceptable proposal and wants to implement it, I'll be happy to support it. |
I have experimented with this feature in my Rust implementation of Jsonnet, what do you folks think about this? |
Nice! Some questions:
If we can agree on semantics I'm happy to upstream this (unless @sparkprime protests). |
Yep, serialization order is applied deeply I always put overriden fields after untouched, however i think In object comprehensions fields are ordered by insertion, i.e {[k]: 1 for k in ['b', 'a', 'c']} will have b, a, c ordering |
Yeah. I expect the most common case would be to have a big object with fields in expected order and then override some of them. It would be annoying if this would always put them in the end.
Sounds reasonable. |
I have played with this feature couple of days, and i think about this as better behavior: Both overrides and {a: 1, b: 2} + {c: 4, a: 2, b+: 1}
// =>
{a: 2, b: 3, c: 4} Originally i was resetting position of overriden field to have better understanding for where this field was defined, but this breaks cases like {apiVersion: error "missing api version", kind: error "missing kind"} + {kind: 'Pod', apiVersion: 'v1'} For my usecase i should better think about something like {apiVersion: <overriden>, kind: <overriden>} + {kind: 'Pod', apiVersion: 'v1'} |
Per discussion in google/jsonnet#903 Signed-off-by: Yaroslav Bolyukin <iam@lach.pw>
Agreed. I like your approach and would be happy to make it official.
This technically breaks some laws that |
I suggest to add the feature of preserving the order of list items when converting to json, maybe as an option. If available, please add it to the manual.
The text was updated successfully, but these errors were encountered: