- Arrays allow trailing commas!
- Comments! (From a JSON perspective, that's huge!)
- Dates are UTC!
- Simple syntax, no semicolon / commas, no need to check for matching braces!
- No way to go back to the global hash. Once you go down one level, can't go back up!
inGlobal = true
[keygroup]
inKeyGroup = true
# Here, you can't add a key to the global hash!
-
You can't have mixed data in arrays unless they're both one level deep!
So, it feels like arrays are typed, except that empty arrays are not.
key = [ [1], ["foo"], [] ]
- You can't have hashes inside arrays!
# That really should be an array.
[dependancy1]
groupId = "com.google.api-client"
artifactId = "google-api-client"
version = "1.13.2-beta"
[dependancy2]
groupId = "com.google.api-client"
artifactId = "google-api-client-servlet"
version = "1.13.1-beta"
- The specification is lacking!
- A document in UTF-16 / Windows 1252 must change encoding to UTF-8 in each string!
- What happens when the keygroup is the empty string?
- Lots of (informally-specified) things you can't encode: keys with
=
in them, keygroups with]
in them… (The current spec allows=
in keys by not forbidding it.) Which special characters are allowed in keys anyway?
Alternative: the Settings File Format.
Right. I really hope it gets merged!
Currently working in LAMP on Scala stuff gives me a free pass away from this accusation! ☺
That said, as long as the aforementioned patch gets merged, the design of arrays allows
[ [1], ["1"] ]
, which can't be optimized that well for statically typed languages.It will also be hard for current implementations to update that requirement, when the patch is applied.
The current spec
has the example of working around a file encoded in Latin-1.
I believe files encoded in non-UTF-8 should simply be rejected as soon as a character clearly isn't UTF-8; that's how I specified dotset.
I wished it was at least as precise as the format I published after him…
and I hope that patch gets merged.