Open tylerjw opened 3 months ago
It would be easier to tool against this if it read:
Note that a null value is the same thing as not specifying the attribute. To suppress
falling back to the non-configuration-specific value, specify a valid value such as
0/""/[]/{}.
I found another use of this sort of special-casing null here: https://cps-org.github.io/cps/schema.html#requires-package
Values are a valid requirement object or null (equivalent to an empty requirement object)
describing the package required.
I prefer this wording for the sake of tooling:
Values are a valid requirement object or an empty object.
Imho we should simply remove that. This also makes it harder to write a schema for it.
I prefer this wording [...]
Yes, I guess we should change that also, but an empty object is a valid Requirement; "or an empty object" is redundant.
Values are a valid requirement object
describing the package required.
In JSON parsers, where you specify a structure of types and the parser tries to fill out those types, typically an unset attribute and an attribute set to null both results in a None value in an optional. In cases where you must tell the difference between an unset value and a null value, you'll end up with a nested option type. This makes it much more challenging to tool around this spec.
It would be much easier if
tag: null
meant the same as the tag not being specified. If you want to unset the values and not allow a fallback, set the value to an empty string or array. For exampletag: []
ortag: ""
would cause an overriding to an empty value.