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