musikinformatik / jsonlib Goto Github PK

@LFSaw suggested that having a pretty printer for the object to string method would be nice and I agree - I used vscode multiple times to make the JSON look more convenient during debugging, and after all, JSON is a human readable format and its reference implementation in JavaScript also offers this feature natively.

Examples

I looked up the JS and the Python implementation and they both offer adding an indentation in their "transform object to string" method

JavaScript: JSON.stringify

space
A string or number that's used to insert white space (including indentation, line break characters, etc.) into the output JSON string for readability purposes.

If this is a number, it indicates the number of space characters to be used as indentation, clamped to 10 (that is, any number greater than 10 is treated as if it were 10). Values less than 1 indicate that no space should be used.

If this is a string, the string (or the first 10 characters of the string, if it's longer than that) is inserted before every nested object or array.

If space is anything other than a string or number (can be either a primitive or a wrapper object) — for example, is null or not provided — no white space is used.

Python: json.dumps

indent
If indent is a non-negative integer or string, then JSON array elements and object members will be pretty-printed with that indent level. An indent level of 0, negative, or "" will only insert newlines. None (the default) selects the most compact representation. Using a positive integer indent indents that many spaces per level. If indent is a string (such as "\t"), that string is used to indent each level.

Implementation: https://github.com/python/cpython/blob/ffb41eaaf4b04f7f52ee095253fcc1c5ba62ca28/Lib/json/encoder.py#L288-L295

I don' t really understand the length of 10 restriction in JS, so maybe just copy the python behavior as it seems to cover pretty much anything?

UNIT TESTS FOR 'TestJSONlib' COMPLETED
There were failures:
a TestJSONlib: test_stringsDecode - Hex encoding should not affect ascii chars lorem

Although I prefer the more OO based approach we should also implement add methods to existing classes which is the more common thing to do in SC.
Within the added methods we can simply use the JSONlib class.

+ Dictionary {
    asJson {
        ^JSONlib.encode(this);
    }
}

The problem is the parsing as there already exists a parseJson method which is not really what you want, so a proper naming should be discussed.

Thanks again for this wonderful add-on, I use it all the time :)
I was wondering:

There's a (simple) extension to json called json5 that especially includes comments and is targeted towards human readablity. Might be worth looking into to support?

Example from the website:

{
  // comments
  unquoted: 'and you can quote me on that',
  singleQuotes: 'I can use "double quotes" here',
  lineBreaks: "Look, Mom! \
No \\n's!",
  hexadecimal: 0xdecaf,
  leadingDecimalPoint: .8675309, andTrailing: 8675309.,
  positiveSign: +1,
  trailingComma: 'in objects', andIn: ['arrays',],
  "backwardsCompatible": "with JSON",
}

A more real-world example is this config file from the Chromium/Blink project.

I think it would be neat to allow for custom parsing functions - this would allow e.g. to dump function source code in a JSON file which then could be encoded into a function again during parsing.
As this is not part of the official JSON implementation we should not implement it in this lib, but we should allow people to use hooks for this, see e.g. how the python implementation of JSON solves this https://docs.python.org/3/library/json.html#json.JSONEncoder as an inspiration

Do you wan to clean the history of the repository or open it as it is? It was developed in closed form, so this needs to be ckecked.

There is still room to make the array and event documentation a bit bigger :D

noting these issues, relevant for JSONlib as well:

• supercollider/supercollider#5988
• supercollider/supercollider#5946

in the end one should be able to do

(\foo: 42).asJSON(customEncoder: {})

Add a crossover logo b/c the JSON logo is simillar to the SC IDE one.
Optional.

Maybe as a last step before release so the interface does not change.

To cover:

• Dictionary vs Event
• Cover deviations from the standard
  • #18
  • The null/nil issue (see #5 )
• Cover problems of implicit casting ({"foo": "42.0"} will become (foo: 42.0) instead of a string)

Bonus:

• #19

should be "null", no?

v == "null"

A good example is (2: "hello", 1: "word") – this won't be reconverted to itself, but to ('2': "hello", '1': "word"). Similarly, dictionaries that have parseable keys, like arrays of strings.

This is not a big issue, just saying.

Maybe there is a resource for hard-to-parse JSONs with lots of edge cases concerning

• escaping in string (", and \)
• number parsing like .5 or 10e4
• invalid escaping

See json.org for the implementation details

TIL

// does not work
(\a: nil);
-> (  )
// does work
(\a: Nil);
-> ( 'a': class Nil )

So its probably best to use the build in data type