On: JSON has become today's machine-readable output format on Unix

[enriquto]

> How does your approach handle keys with spaces?

It doesn't, and that's OK; not a big deal.

JSON has no support for standard floating-point numbers, and that's a bigger problem for me. I can easily change my keys to make them sane, but I cannot change the numbers!

[Timon3 → enriquto]

> It doesn't, and that's OK; not a big deal.

It's only not a big deal if your use case doesn't require this feature.

You don't always have full control over the keys. Say I take over your legacy project, and I need to add a way to configure settings related to file paths. Whoops, suddenly I'm either limited in the FS layout I can use, or I have to implement support for this feature (and properly test it, and document it, and...)

> JSON has no support for standard floating-point numbers, and that's a bigger problem for me. I can easily change my keys to make them sane, but I cannot change the numbers!

You can always encode them as strings, no?

[aragilar → Timon3]

How do you tell the difference between a string and a number then (also, what precision is the number, is it a float or an int etc.)?

[Timon3 → aragilar]

Depends! If you know the schema, you already have this information. If you don't know the schema, the most common approach is to store the type and value in an object, e.g.

    {
        "_t": "float64",
        "_v": "3.14159"
    }