Re: Next YAML: drop equality definition

Oren Ben-Kiki <[email protected]> Fri, 4 Mar 2016 17:40:09 +0200
Newsgroups gmane.text.yaml.general
Message-ID <CADJiDhvJqKTrcs2+hQ-tH-uuKrWGYak0=uZqdidnvy_NmhoWWQ@mail.gmail.com>
Ah, key equality all over again...

I think the spec is actually OK here.

It reasonably asks for a canonical form for scalars - this is equivalent to
the application providing operator== which is a basic requirement for keys
and in general (but see below).

It allows but does does not require the implementation to do very limited
"early detection" of key equality. For example, two scalar keys of the same
mapping which have exactly the same content must resolve to "equal" keys,
regardless of the tag resolution rules and the application. So this *can*
be flagged early. But there's no such requirement for such early detection
in the spec. In practice, many implementations will enforce this due to
using simple hash tables to implement partial representations.

It allows a YAML processor to "intern" scalars (e.g. strings), or use
shared_ptr to them, etc. This may improve performance. But it does not
require such a mechanism, allowing for simpler implementations.

It forbids a YAML processor from "intern"-ing/sharing complex nodes
(sequences, mappings). Which seems like a good conservative approach.

I'm not averse to tweaking the wording on a YAML1.3/2.0/whatever. For
example, relaxing the equality detection requirement to happen only during
construction, so a complete representation may still include equal keys.
That is, we can apply a schema to assign tags to the nodes, but still not
have any clue what these tags _mean_. That seems like a cleaner cut-off
point between a complete representation and the native data. What the spec
calls now a complete representation would be a canonical representation -
something which is useful, but not required in many cases.

But that issue doesn't seem to be the one raised here; the problem seems to
be with the "early duplicates detection". Which, again, is explicitly not
required by the spec. So I'm not certain what the actual problem is with
the current rules. Is this a case of the perceived rules being different
from the actual rules in the spec?

Oren.

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140

_______________________________________________
Yaml-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/yaml-core