Closed bboudaoud-nv closed 3 years ago
I left a comment in #316, but I'll repeat it here as well.
I personally prefer the C++ style .Any
format, so I'm not sure why we should force JSON compatible .Any
output universally. Is there a reason to turn this on all the time other than just making the data files explicitly JSON?
As an example, I typically set my editor to use C++ syntax highlighting for .Any
and it works quite well, plus I can copy-paste data from C++ into .Any
and vice versa. I also strictly author experiment configs using the C++/python style and not the JSON style.
This wouldn't break my flow to output autogenerated files with the JSON format, but it would be annoying for dealing with the user status when I want to modify it by hand.
To be clear, I'm not opposed to having JSON compliant output as an option, I just don't see the reason to make that the default. Perhaps an "export to JSON" button could save out all *.Any
files to matching *.json
files for any tool that wants JSON compliant files for whatever reason.
When calling
Any::save(filename)
the file output is assumed to not be JSON compatible unless the providedfilename
ends with a.json
extension.Incompatibilities include:
=
is used instead of:
;
instead of,
( ... )
instead of[ ... ]
G3D can support a "quick fix" here by adding an (optional)
json
argument toAny::save()
(as is done forAny::serialize()
) or we can write our own method. If @jspjutNV can get this added to G3D its likely easier to do the former and add atrue
for this new parameter to make Any's serialized out from FPSci JSON parse-able.If we do this perhaps we should consider harmonizing all of our example docs on the JSON standard formatting...