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.
> 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.
