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.
Yes, and the same for [1.0] cmp [1]. Changing the semantics of "=="
could work, but then we need another operator for when we do want types
to match. So adding a new operator that doesn't check the type, only
the effective value, could be the solution. We also still need an
operator that avoids that '' and zero are deemed equal:
echo '' == 0
1
Which is actually the opposite of making something less strict than ==.
Darn. We can't change that without breaking lots of scripts.
That could be done with "===" (like in Javascript, type must match).
But we still don't have something for "equal value". So we would need
yet another operator. "=*=" ???
--
Bumper sticker: Honk if you love peace and quiet.
/// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
--
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.
