Re: YAML 2.0: drop arbitrary nodes to be used as keys
Andrey Somov <[email protected]> Wed, 2 Mar 2016 18:18:20 +0100
| Newsgroups | gmane.text.yaml.general |
|---|---|
| Message-ID | <CALbkv0fbZ488AJZmMybAtoBCimv__-Xd5jUxayF-9e=KR8BjHg@mail.gmail.com> |
On Wed, Mar 2, 2016 at 6:06 PM, Geoff Adams <[email protected]> wrote: > I wrote a libyaml wrapper for Matlab, a language which doesn't even have a > real native mapping type (or didn't until very recently, and it's sort of > kludged on), meaning there's no native type to easily represent mappings > with scalar keys which aren't strings. However, the most common YAML > mappings, with scalar string keys, can be naturally represented with > Matlab's struct type, and 95% of the time this is definitely what the user > wants. I chose to provide a generic representation, where YAML mappings > are represented in Matlab as a list (cell array in Matlab parlance) of > key-value pairs, as well as a specialized representation for those mappings > which Matlab can represent as structs, and allowed the user to select which > is appropriate for the application. This same strategy is applied for > non-scalar keys. > > I think this is a more appropriate strategy for parsers in languages which > do not offer a simple native-type representation of non-scalar mappings (or > any other useful YAML feature). If your users are telling you you need to > change your YAML because they can't parse it, the problem is that their > parser is not standards-compliant, not that the full YAML spec is > impossible to implement in their language. Any language that offers at > least nested mixed-type lists (or some other representation of a mixed-type > tree) should be able to represent any YAML document, even if that > representation is less "natural" than it would be in a different language. > > Short version, don't drop useful features from YAML 2.0 just because > they're inconvenient to implement in some languages. If it can work in the > arbitrary mess that is Matlab, it can work in your language. > I do not say that we should drop it because it is inconvenient to implement in some languages. I say that it should not be there at all !!! This is the same as implicit types (http://yaml.org/type/index.html) which will be fortunately dropped. If something can be done, does not mean that it should be done. > Best, > Geoff > ------------------------------------------------------------------------------ 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