On Wednesday 03 May 2006 12:00, Kirill Simonov wrote:
> The problem is that the process of merging is described in terms of
> "nodes". Therefore it is required by the spec that the value of the
> merge key is not converted to a native object.
The spec does say "nodes", but this line of reasoning leads to the
conclusion that !include and !merge are impossible in the first place -
they are both "nodes" that mysteriously vanish/mutate at some point!
Loading is inevitably an incremental process. The spec implies a "bottom
up" approach already, e.g. tag resolution of a node may depend on the
total of the node's content, but not on the content of sibling nodes.
Now, in principle, each node is converted to a single native object (or
"cave drawing" as Ingy likes to say). However, reflecting on this for a
second it is obvious that when a collection node is loaded to some
"cave drawing", there need not be a 1-1 mapping from some specific part
of it to a particular node contained in the collection. If we had
placed such a restriction, we would no longer allow for _any_ sort of
"cave drawing" to be used. An example of this is our !set notation. All
the null value nodes "disappear" when we load it into a new Ruby "Set"
Taken together, I think it is inevitable that loading keys such
as !include and !merge is done as a bottom up process that uses the
node structure (and tag) as _input_, but has no further restrictions on
its behavior. It is good we have !include and !merge in the spec to
drive home this point. After all, if this were not the case, !merge
and !include wouldn't be possible in the first place.
In fact, !merge and !include demonstrate another important concept. In
general we expect that loading YAML nodes to "cave drawings" be a
reversible process (aka "round tripping"). However, the spec makes no
such hard requirement. It is certainly _desirable_ in many cases to
build a round-trip system, but it is also desirable in other cases to
build a load-only (or dump-only) system. The spec intentionally does
not preclude such systems. A system that supports !include and !merge
is _typically_ "load only". Dumping the content back would _typically_
simply dump the included/merged keys, which - again - is intentionally
OK under the spec, as long as it is understood by all parties that the
result is "not the same" as the original YAML document.