I understand your âstrictnessâ argument from a technical perspective, but Iâm curious what benefit would be provided to TOSCA authors by enforcing this strictness. Is there any ambiguity that would be eliminated
or errors that would be prevented?
1) It allows users to see at a glance exactly what is missing: whether it's a list or a map. TOSCA syntax can be a bit confusing and inconsistent sometimes, so it's nice not to have to look it up in the spec (e.g. requirement assignments, node filters, etc., which use sequenced lists rather than maps). Of course, if we ever get a nice TOSCA IDE life would be easier. (I'm working on it here and there...) And sure, supporting YAML's implicit null is shorter, but I always err on the side of verbosity if it increases clarity. And also, sure, the only potential ambiguity is in the mind of the user, but I prefer that even the potential would not exist.
2) Nulls are always tricky sources of bugs. Of course, a good parser should know what do if there is a null, but it's easy enough to imagine subtle bugs somewhere down the line because someone left the value as a null rather than an empty list/map. This ends up very language dependent. For example, a null in Python is always of the null type. A list() or dict() value are typed and empty. Meanwhile, in Go even though every var is typed a slice can work as a null value (empty slice) but a map requires explicit allocation and will NPE otherwise. So, sure, good programmers would read the spec and know what to do, but it just makes life a bit harder.
Anyway, just a preference on my end. If people really like the null it's fine. Either way we should make a note to clarify this in the spec.