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