From: Zenaan H. <ze...@fr...> - 2016-03-03 22:05:29
|
On 3/2/16, Andrey Somov <pub...@gm...> wrote: > On Wed, Mar 2, 2016 at 6:55 PM, Osamu TAKEUCHI <os...@bi...> wrote: > > If someone has ever complained, that proves there is actually some >> application >> that uses the ability of YAML to store a hash with complex keys, isn't >> it? >> >> > You missed the whole idea of my argument against complex keys. > Of course it is used by someone. > But is should _not_ be used. Every project will find another solution. > Community wins. I too want YAML to be the best YAML, for serialization and for human readability (and human writability). I have been thinking about an actual use case (perhaps you can link to a few of the "many issues" you say SnakeYaml users have faced... real issues, rather than stated preference, can galvanize opinion): I saw a graph many years ago, which was of countries, with debt on X axis, some other national wealth indicator on Y axis, and each country was a dot, with the size of the dot representing some third piece of data. The country name was also displayed. Of course, the application representing such a graph could "index" with country name, or with point location pairs (x,y), or even with just a specific value (just x, or just y, or just the third value - the size of the dot). So there are a few options, superficially. BUT, to -limit- the possible keys, could limit the optimal representation format for the application - for example, there might be more than one graph, with the same set of dots, but with alternate sizes for some alternate piece of data, where the X and Y are the same (the "natural" basis of the graph) - and so, disallowing point (x,y) keys in the serialization format then imposes on the application doing the serializing a need to work around that limitation, choosing a "key" which is other than ideal, and/ or which may even introduce undesirable characteristic - e.g. unnecessary data duplication (which, if the data could be edited by humans, is definitely to be avoided, and definitely more so with human data editing you want the "most natural" representation/ serialization format, of that data). Even hash maps and trees can be simulated or "simplified" to lists (e.g. to "simplify the syntax") - even strings are just a list of characters. The point is, to simplify, but to not over simplify for the particular target use case. YAML has certain targets. JSON has certain targets. It may well be, that what you (and I and others) could really benefit from is a JSON 2.0. I don't know for sure, just hypothesizing. I have been somewhat disappointed over the years of the lack of widespread adoption of YAML which I assumed for so long (and still assume, may be naive) should happen - and then, the indignity of it all, this pipsqueak upstart JSON leaps onto the scene and half the world gapes in awe, like come on, that's ridiculous! So perhaps there is room for something a bit different to either, although perhaps it's better to call it JSON 2 or YAML 2. Good luck all, Zenaan |