Debug print (toString / str / to_s / repr / inspect / etc) implementations

[GreyCat]

Currently, the classes we generate are not very string conversion friendly. Many languages feature some kind of debugging print aid (like toString() or repr or stuff like that) that allows us to customize what would be printed out during to string conversion of an object.

From bird's eye perspective, there are two major variations of that feature:

• In some languages (Java, C#, at, to some extent, C++) it's easier to generate toString-like method that would print out
• In some languages (Ruby, Python, PHP, etc), it's probably easier to implement relevant code in KaitaiStruct that would achieve the same using reflection

Doing that should probably make debugging print much easier for all languages. Right now only Ruby and, to some extent, JavaScript, does sane debug printing.

[GreyCat]

Just for the record, @KOLANICH pioneered Python __repr__ implementation:
kaitai-io/kaitai_struct_python_runtime#10

[webbnh]

Just a random thought....

On my project (and, I've heard others mention it as well), our principal use of KS is to convert a binary data structure into a JSON representation. To accomplish this, we use KS to read the binary, and then we use a second layer of code (also generated from the KSY file) to call the KSC-generated code to complete the transposition.

It would be quite handy if the mechanism proposed here could produce JSON (or a JSON-formatted string). That would obviate a huge chunk of infrastructure that I've had to create to close this gap in a general way.

[GreyCat]

@webbnh Actually, that might be a good idea as well. Probably this one is relatively bulky and not required by many, but it's easy to generate similar toJson() everywhere. Probably it warrants something like --generate-to-json option for compiler.

[webbnh]

From where I stand, there's not much difference between toString() and toJsonString(). That is, the former would (presumably) produce a string with a list of field-name/field-value pairs; the latter would do the same thing, only formatted according to JSON rules (with lots of braces, brackets, and escaped, nested quotes).

If you think the generation of the latter should be controlled by a compiler switch, I would think the generation of the former would want the same. (I mean, toString() is a handy debugging tool, but I don't think it would be widely used in production.) On the other hand, having a single toString() function with the command line switch controlling how it is formatted might be good.

[GreyCat]

@webbnh Actually, you're right, it might be a good idea to make both toString() and toJsonString() enabled by default and add CLI switches to disable both.

I don't think that we have the user to choose between these two. toString() would likely produce something that follows the language-specific standard for such debugging output, and toJsonString() would likely offer standard JSON output, same one for all languages.