On Thu, Feb 4, 2016 at 10:08 PM, tyru <[email protected]> wrote: > Hi Nikolay, > > Thanks for lots of follow-up examples :) > > On Thu, Feb 4, 2016 at 8:33 AM, Nikolay Aleksandrovich Pavlov > <[email protected]> wrote: >> Since that thread is over I would reply here (did not reply previously >> because I did not realize that json and channel features are >> connected) > > BTW, I didn't understand why json and channel features are connected. > I only talked about JSON feature. > >> >>> The question is what to do with items that can't be converted to JSON. >>> I have been in doubt, whether to silently drop them or give an error. >>> >>> Although a missing item in an array is not according to the JSON >>> standard, it is very useful in practice: >>> >>> [1,,,,8] >>> >>> The missing items would be "undefined" in JavaScript. In Vim they are >>> v:none. Proper JSON would be: >>> >>> [1,null,null,null,8] >>> >>> That's more than twice as long. Gets worse when there are more missing >>> items, up to five times as long. >> >> 1. Arrays like `[1, null, null, null, 8]` are very rarely used when >> communicating. So this is almost never “twice as long”. Especially >> with the planned subfeatures of the channel feature. >> 2. `[1,,,,8]` with the current parser is `[1, v:none, v:none, v:none, >> 8]`. If people are testing for null values using `if {val} is v:null` >> the fact that it can be written like this is absolutely useless. If >> people are using `if {val}` this can be as well written as >> `[1,0,0,0,8]`. >> 3. I have no problems in counting three null values, but commas are >> harder to count and they are usually visually skipped because of >> having very low importance. >> 4. Computer has no problems with either variants, performance impact >> is negligible. >> 5. Handling v:none in VimL in case somebody cares code adds *far* more >> ticks then parsing `null` in C code. >> 6. It is easy to miss v:none in cases like >> >> [ >> "1" >> , "2" >> , "3", >> , "4" >> ] > > This is very likely probable case! > The following JSON string leaves v:none at the end > if it is parsed by current jsondecode(). > > [ > "1", > "2", > "3", > "4", > ] > >> 7. In msgpack the whole array is six bytes. JSON is more then three >> times as long. Non-JSON you propose is still 1⅓ longer. For IPC it is >> better. For user YAML is more readable (especially when one needs >> multi-line strings), and almost always can be made less verbose then >> JSON. >> 8. In javascript `[1,,,,8]` is `[1,undefined,undefined,undefined,8]`, >> not `[1,null,null,null,8]`. >> >>> >>> I propose to allow this extension to JSON. However, it should not be >>> created accidentally, only when intentionally using v:none as an item. >> >> If documentation states that channel accepts JSON, it should accept >> JSON and not something else. I am not much fond of idea of >> jsondecode() extensions, but do not create *yet another* standard in >> interprocess communications, this action is worse then creating yet >> another non-strict parser. >> >>> >>> So, we should probably give an error when using a function, instead of >>> producing JSON that's not according to the standard. >> >> 2016-02-03 16:28 GMT+03:00 tyru <[email protected]>: >>> Dear Bram and Vimmers, >>> >>> I have read the below thread. >>> >>> [vim] jsonencode() does not work correctly with function references (#579) >>> https://groups.google.com/forum/#!msg/vim_dev/9rf5_YmPn28/qZKB3rKvCAAJ >>> >>> But, I couldn't understand why Vim has had to add v:none variable. >>> >>>> Although a missing item in an array is not according to the JSON >>>> standard, it is very useful in practice: >>> I don't think so. >>> If v:none variable has been added because *only* it is useful, >>> it should not be. >>> I don't think It should be added even breaking the JSON standard. >>> >>> Because, v:none and v:null is very similar. >>> If a user mistake v:none for v:null, >>> an invalid JSON (for strict JSON parser) will be generated! >> >> I can also confirm that I need to constantly remind myself what >> exactly I need to use. >> >>> >>> jsonencode([1,v:none,v:none,4]) >>> >>> "undefined" and "null" in JavaScript is totally a bad part. >>> Please don't follow that. >> >> It would be better if you have shown (pointed to an article) what is >> so bad here. > > "undefined" and "null" are totally different things. > So "undefined === null" returns true, of course.
oh sorry. of course "undefined === null" returns false :) > But both values mean often an absense of a value. > They are very confusing. > >> >>> >>> Best wishes, >>> >>> tyru >>> >>> -- >>> -- >>> 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. -- -- 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.
