2016-01-25 12:51 GMT+03:00 LCD 47 <[email protected]>:
>
> On 25 January 2016, Nikolay Aleksandrovich Pavlov <[email protected]> wrote:
> > 2016-01-25 0:26 GMT+03:00 LCD 47 <[email protected]>:
> >
> > > On 24 January 2016, Bram Moolenaar <[email protected]> wrote:
> [...]
> > > > 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.
> [...]
>
> First example: syntastic. Syntastic is a plugin that runs various
> linters against a file, parses their output, and puts it in a quickfix
> list. Some of these linters produce more precise reports when told to
> output JSON, and syntastic uses this function to parse said reports:
>
> https://goo.gl/ca8Tzb
>
> The result is a list of error items, intermingled with statistics,
> pointers to docs, and the like. Syntastic filters the useful parts out
> of it, sorts the items, and reformats it for setloclist(). If I were to
> switch from the function above to jsondecode(), I'd have to either redo
> sorting to accomodate for v:true and v:false, or normalize the list to
> use 0 and 1 instead.
Can you show the sorting code? With default sorting algorythm used it
is OK to have `string(v:true) == 'true'` and `string(v:false) ==
'false'` as long as `'false' <# 'true'` which is true. This will not
change when switching from `'false'` to `'v:false'`.
>
>
> Second example: parsing logs from a meteo station and producing
> reports. I have a small meteo station that produces a list of hardware
> events. Again the more useful format for the logs is JSON, and again,
> I'm using a function similar to the one above to parse it. Some
> events are duplicated, and I'm picking up only the first in a series.
> Comparisons would have to be redone if I were to use jsondecode().
If you were to compare two log items parsed with jsondecode it is
enough that [v:true] == [v:true]. This works.
>
> Granted, most of this (but not all) could be done in Python, but the
> point is, the v:null in jsondecode() is complicating things.
v:null? Or v:none?
>
> In both cases I'll probably keep using the scrub and eval() function
> to parse JSON. It's fast, it does proper error validation, and the
> output is easy to work with. If I'd need to save and restore states
> to disk as JSON, I'd probably also do it with a Python function over
> jsonencode() and jsondecode().
It would be more useful if you performed just one test: replace the
function you referenced with the below code and say what breaks:
```
function! s:_decode_JSON(json) abort " {{{2
try
return empty(a:json) ? [] : jsondecode(a:json)
catch
return ''
endtry
endfunction " }}}2
```
---
Though I would not say I am fond of spec incompatibilities, especially
v:none. JSON parser should parse JSON, not somebody’s own spec. I am
pretty sure that if I wrote the above code to throw errors on v:none
it would run slower then your eval()-based variant due to breaking
main VimL optimization principle: the less commands run the better.
Though I think I was able to construct an expression that checks
whether there is v:none somewhere inside the list than needs only two
commands:
let tocheck = [object, 1]
call map(tocheck, 'type(v:val) == type([]) || type(v:val) ==
type({}) ? extend(tocheck, (type(v:val) == type([]) ? v:val :
values(v:val)) + [1]) : (v:val is v:none ? foo() : v:val)')
(will throw `E117: Unknown function: foo` when checking structures
with v:none inside). But if you do not want to write hacky code this
will be a cycle with :if’s and cycle with :if’s breaks this principle.
I think this code needs to be put in the documentation to scare users
willing to use jsondecode() :)
>
>
> /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.
