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