|
|
|
|
|
|
by ajanuary
1000 days ago
|
|
|
The problem with YAML as a configuration format can be boiled down to two things:
1) significant whitespace; that one is obviously subjective
2) encoding types in the document When I’m reading the `maxItems` property from it, I know it’s an integer. Why do I need the document author to also tell me it’s an integer? For statically typed languages, you have to tell it what type you’re expecting, so it can interpret the value at that point. `config.getInt("maxItems")`. Even for dynamic language, most of the time you still want to validate the types up front to avoid an incorrect type blowing up in a random place in your code. So write a schema, use the schema to drive how the values are interpreted. By replacing all the non-structural types with string, you can have the clean quote less format they’re after but without any of the “Norwegian problem” issues. |
|
|
Because this allows well-designed client libraries to detect conflicts between the document-author intent and programmer intent, enabling mismatches to fail as errors rather than being read other-than-as-intended.
> For statically typed languages, you have to tell it what type you’re expecting, so it can interpret the value at that point.
Yes and a client in such a language should fail (or have a mode in which it fails) if the value is not actually, as read in YAML semantics, a type compatible with what you are asking for.
> Even for dynamic language, most of the time you still want to validate the types up front to avoid an incorrect type blowing up in a random place in your code. So write a schema, use the schema to drive how the values are interpreted.
Schemas are for validation, not interpretation. If you use them for interpretation, then you get JavaScript-esque weak typing, and the errors that come with it (basically, magnifying the kind of YAML 1.1 problems that YAML 1.2 tamped down.)
> By replacing all the non-structural types with string, you can have the clean quote less format they’re after but without any of the “Norwegian problem” issues.
What you propose is an explosion of Norway-problem-style potential for values to be interpret other than as intended by the document author, not a mitigation.