this post was submitted on 05 Apr 2024
27 points (84.6% liked)
Technology
59106 readers
5643 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
YAML to JSON is probably doable, JSON back to YAML not so much.
There are multiple ways to mark multiline strings in YAML. Then there are anchors, like bionicjoey mentioned. Also comments, YAML has them. You'd have to have some way to retain the extra information, if you want to make the full round trip.
Here's an example:
converted to JSON looks like this
All JSON is valid YAML, so after you've converted the file to JSON, just... save it with a YAML file extension and call it a day..?
Comments are an issue I'd have to think about. Would prebuilt libraries for importing/exporting data from/to these languages not handle the multiline strings for me?
What do anchors do in yaml I've never heard of them before
I think the difference is that it sounds they are just looking for something JSON-like, just enough to edit and save a change. It might not need to be valid.
So, a new not-a-markup-language, only human readable and editable, and objectively better than its predecessor? Well, it's all according to tradition. I believe YAML got its start the same way.
That's hilarious. I didn't know that
No, I was thinking of actual JSON because it makes it easier to write a plugin (just use built in libraries to import and export configurations)
That said I suppose I could use the built in library and then re-inject comments after the fact
Oh, my mistake. Disregard me then.
Not a terrible idea to add bits into the JSON but it makes it much harder to program, going for a quick and easy fix here rather than writing my own parser
Maybe a 3rd file would work? You could add all of the relevant data there and when translating between one language or the other it would prune any comments or unsupported features as the output is generated.
My plan is not to have multiple files at all and only have the JSON be in memory, or at least if there is a second one have it be temporary and deleted on exit
The problem with the approach of having an intermediary format is I need to create the intermediate format, and given yaml starts for yet another markup language that doesn't seem like a good idea (also a ton of effort to reinvent the wheel)