11–20 of 31 posts
INI, JSON and YAML all have problems. None of them are serious enough for me to consider this for a small project with one or two config files required. Good to be able to point to a config file syntax done right though.
The format could be very simple, but... allowing comments after values make it unnecessarily complex to parse. For example: value = "example # no that's not a comment" # but here's one If inline comments where not allowed we could just check the first and last character for a quote and we know we have a string, same for arrays (check for [ and ]). But with inline comments, we need to parse the whole string. As far as…
INI, JSON and YAML all have problems. None of them are serious enough for me to consider this for a small project with one or two config files required. Good to be able to point to a config file syntax done right though.
Do tell about the problems with JSON for use as a configuration object? Almost every language has a library that can parse JSON.
I personally never jumped on YAML or JSON. I liked that they weren't XML, but they each felt like XML++ too much for me. There was still too much, I don't know, weirdness/typing/oops! Don't get me wrong, I think they were better than XML, but only marginally. It would be nice to see more of a phase change type of approach. I'd LOVE to see something like this (or something else) that involves much less typing/special characters/etc than YAML and JSON.
Personal opinion.
I don't know if this is the answer, but I'm a fan of someone trying. I personally never jumped on YAML or JSON. I liked that they weren't XML, but they each felt like XML++ too much for me. There was still too much, I don't know, weirdness/typing/oops! Don't get me wrong, I think they were better than XML, but only marginally. It would be nice to see more of a phase change type of approach. I'd LOVE to see something…
I don't know if this is the answer, but I'm a fan of someone trying. I personally never jumped on YAML or JSON. I liked that they weren't XML, but they each felt like XML++ too much for me. There was still too much, I don't know, weirdness/typing/oops! Don't get me wrong, I think they were better than XML, but only marginally. It would be nice to see more of a phase change type of approach. I'd LOVE to see something…
INI, JSON and YAML all have problems. None of them are serious enough for me to consider this for a small project with one or two config files required. Good to be able to point to a config file syntax done right though.
Do tell about the problems with JSON for use as a configuration object? Almost every language has a library that can parse JSON.
I don't know if this is the answer, but I'm a fan of someone trying. I personally never jumped on YAML or JSON. I liked that they weren't XML, but they each felt like XML++ too much for me. There was still too much, I don't know, weirdness/typing/oops! Don't get me wrong, I think they were better than XML, but only marginally. It would be nice to see more of a phase change type of approach. I'd LOVE to see something…
How many less characters could there be while still maintaining meaning? Could you show an example of what you'd prefer?
"Less" characters? Do you mean physical smaller characters, like "e" instead of "E"? Or do you perhaps mean fewer characters?
INI, JSON and YAML all have problems. None of them are serious enough for me to consider this for a small project with one or two config files required. Good to be able to point to a config file syntax done right though.
1. If indentation is significant and required, dotted notation should be optional:
[foo]
[bar]
[car]
2. Support include files. With #1 implemented, includes would be extremely powerful and flexible. Since indentation is required, no special syntax is needed to relatively position the included files. And without requiring dotted notation in keys, include files can be reused in a configuration (such as common settings in the [servers] section of the example).