Skip to content

feat: add utility function to write data in path #1058

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

matteo-cristino
Copy link
Collaborator

seems a good start, but it need a lot of testing

@jaromil
Copy link
Member

jaromil commented Apr 30, 2025

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

@matteo-cristino
Copy link
Collaborator Author

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)

@jaromil
Copy link
Member

jaromil commented May 7, 2025

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

@matteo-cristino
Copy link
Collaborator Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants