feat: add utility function to write data in path
seems a good start, but it need a lot of testing
can we reuse or modularize the existing path retrieving function? I haven't checked myself right now, lets just use as less code as possible. agree this has an interesting number of corner cases and your seems a very good start
At the beginning I thought about the same thing, but here you are not retrieving an object from a path, instead you are writing it in a path! Moreover I implemented it so that if the path does not exists it creates it (in the zencode statement I check that the root exists! So that we do not end with stuff without codec in ACK)
The set_in_path internal global function may be more suited for inclusion in zencode_data.lua and maybe we should rename it together with the read one as write_to_path and read_from_path
One thing comes to my mind about this: when finding a number in the path, e.g. table.1, we treat it like a number and search for it assuming table is an array, but table can also be a dictionary with a string key "1"... To overcome this issue we can use square brackets to inidicate array indexing, so something like table[1] will be interpreted as array indexing, while table.1 as dictionary indexing
Yes, I like very much the square brackets and dot notation. A good standard notation for paths.