Re: The special keys (namely merging) in the spec

On Mon, 2009-06-08 at 08:01 -0700, Joshua Choi wrote:
> Ah, I kind of see what you mean.
> 
> But then, how can the merge tag's constructor construct *mapping
> entries*, when it's just a single scalar node in the space of a key of
> a mapping:
> ...
> Normally, nodes are recursively constructed, with the leaves of the
> tree first. How can a scalar constructor of the node, !!merge "<<",
> access the whole mapping entry it's contained in, !!merge "<<": !!map
> { !!str "x": !!int "1" }, without some special rule? Is that a special
> feature of mapping key nodes?

I would say this is a special feature of _this_ mapping key node. I
agree the whole thing is highly magical. I am uncomfortable explicitly
detailing this magic in the spec though; I feel the proper place to
discuss this magic is when defining the "merge" tag. After all, we may
want to introduce other (non-core) tags with other forms of magic...

Admittedly, to support such magical keys, the YAML processor API needs
to be aware of the need for such magic. This means that introducing
magical tags runs the risk of not being supported by YAML processors.
I'd say this is a reasonable trade-off. I don't want to saddle all YAML
processors with the need to support arbitrary magic tags - it seems like
this would place unreasonable burden on implementors.

Some feedback from implementors would be called for here. E.g., Xitology
- what's your take on this?

Have fun,

	Oren Ben-Kiki



------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects