Lcd wrote: > 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
You could still do a string substitute over the JSON before giving it to jsondecode(), to change 'true' to 1, 'false' to 0, etc. > 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. > > 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(). > Granted, most of this (but not all) could be done in Python, but the > point is, the v:null in jsondecode() is complicating things. > > 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(). I suppose what would be useful here is a variant of map() that, when an item is a list or dict, goes into that item, instead of evaluating the expression. perhaps treemap()? That would find each leaf and evaluate the expression, replacing the existing item. Since we already have map() that would not be so difficult to implement. -- Portable Computer: A device invented to force businessmen to work at home, on vacation, and on business trips. /// 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.
