2016-01-25 0:26 GMT+03:00 LCD 47 <[email protected]>: > On 24 January 2016, Bram Moolenaar <[email protected]> wrote: > > > > Lcd wrote: > > > > > [...] > > > > > > > One more thing: adjusting the result of jsondecode() to > contain > > > > > > > only "standard" values involves deep traversal, which is not > > > > > > > trivial. Actually, it's pretty hard to get right. > > > > > > > > > > > > Example? > > > > > > > > > > Anything nested would do: > > > > > > > > > > :echo jsondecode('[{"a":true, "b":false}, null, {"foo": true, > "bar": true, "baz": null}]') > > > > > [{'a': true, 'b': false}, null, {'foo': true, 'baz': null, 'bar': > true}] > > > > > > > > > > Replacing all true, false, and null with "plain" 0, 1, and '' > > > > > means traversing the leaves of this. > > > > > > > > When would that be needed? v:true and v:false can be used in an > > > > expression just like one and zero. I don't know what to replace > > > > v:null with, it must be recognized to know there is nothing there. > In > > > > this example an empty dict is probably what you want, but that's not > a > > > > generic solution. > > > > > > There are situations where what is needed is to extract different > > > things from a large JSON and do something with the values. Having to > > > make a difference between, say, v:true and 1 would propagate all over > > > the place, because: > > > > > > :echo v:true == 1 > > > 1 > > > > > > but > > > > > > :echo [v:true] == [1] > > > 0 > > > > This is unexpected, but the same happens for other items with a similar > > value but different type: > > :echo 1.0 == 1 > > 1 > > :echo [1.0] == [1] > > 0 > > > > Perhaps we should change that as well? It is related to, for example, > > index(): > > echo index([0, v:false], v:false) > > echo index([1.0, 1], 1) > > > > Should these return 0 or 1? > > Both are fine as they are, I don't think either can be changed in a > meaningful way. The difference comes from the fact that v:true, 1.0, > and 1 have different values when converted to strings. No problem here. > > But you asked why would one want to normalize the values v:false, > v:true, and v:null returned by jsondecode() to plain 0, 1, and '', and > this is why: not doing it means they must be handled separately from the > "normal" values. This isn't something that can (or should) be fixed by > changing the semantics of dictionaries, IMO. Changing semanticvs would > lead to even worse problems. >
Can you show real example where you do have problems with handling these values separately? I usually use JSON for configuration or for some simple data bases and for this purposes working :if and type() are enough most of time. > > > We can make it work differently for when using ==. That sort of makes > > sense, even though it's not completely consistent. > > > > > and > > > > > > :echo [v:true] is [1] > > > 0 > > > > That is correct, even: > > :echo [1] is [1] > > 0 > > Yes. My point was, there is no comparison > > [v:true] cmp [1] > > that returns true. > /lcd > > -- > -- > You received this message from the "vim_dev" maillist. > Do not top-post! Type your reply below the text you are replying to. > For more information, visit http://www.vim.org/maillist.php > > --- > You received this message because you are subscribed to the Google Groups > "vim_dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
