ktoml icon indicating copy to clipboard operation
ktoml copied to clipboard

Support encoding of toml format

Open orchestr7 opened this issue 4 years ago • 10 comments

Decoder has the first priority as the Toml usually is used for configuration files, but encoders should also be supported

orchestr7 avatar Apr 11 '21 19:04 orchestr7

I'm working on a rough first implementation of this functionality in this branch. I'm wondering if you have any thoughts on how it should look. Any input is welcome. :)

Mainly, should encoding be done to an AST then written to a file or string, or directly? The KotlinX Json format has encoders for both: StreamingJsonEncoder for writing directly to a string and TreeJsonEncoder for encoding to a tree. From the latter, the Json tree itself is serializable

For the tree-based approach, the Toml AST in parsers.node was obviously written with only parsing in mind. It'd have to be either adapted for both or a separate tree would need to be made (I like the former better, but it'd take some effort).

In the meantime, I'll go forward with it. I can make changes later if needed

NightEule5 avatar Dec 31 '21 10:12 NightEule5

@NightEule5 hello! And thank you so much for this! This is incredible, you can open PR as soon as you will be ready.

Speaking about the AST. We can treat it as an Intermediate Representation. Even right now in Ktoml we have some logic that can help user to read only table names/modify AST on the fly and so on. These things could be useful for encoding also.

So I suppose we need to keep AST (or any other IR) in place. May be we can modify the existing AST somehow?

orchestr7 avatar Dec 31 '21 10:12 orchestr7

@NightEule5 will be great if you would take ownership over the serialization part if it is ok for you.

orchestr7 avatar Dec 31 '21 10:12 orchestr7

Thanks for the response!

So I suppose we need to keep AST (or any other IR) in place. May be we can modify the existing AST somehow?

Yes, I think so. Currently, it looks like much of the parsing happens in the AST classes themselves, right? Maybe we could add a second constructor to the AST classes. If no value is passed for the content property, it could encode the child nodes when invoked

NightEule5 avatar Dec 31 '21 10:12 NightEule5

@NightEule5 will be great if you would take ownership over the serialization part of it is ok for you.

Sure, I'd appreciate that

NightEule5 avatar Dec 31 '21 10:12 NightEule5

@NightEule5 I also suggest you to have a look at what’s Charles is doing in https://github.com/charleskorn/kaml

I love his implementation, may be we can follow his approach after modifying the tree a little bit.

The only thing I am asking about - to split this task into smaller parts, to make PRs small…

orchestr7 avatar Dec 31 '21 10:12 orchestr7

Currently, it looks like much of the parsing happens in the AST classes themselves, right?

Yes, I tried to make it OOP-like. Every Node is an instance where the logic and validation is done. But there are useful interfaces, that can help us to build a tree from class during the serialization process.

orchestr7 avatar Dec 31 '21 10:12 orchestr7

Sure, got it

NightEule5 avatar Dec 31 '21 10:12 NightEule5

Ok, I've refactored the node tree a bit and created low-level file/string writing classes, and tests still pass. Should I create a pull request to the main branch or should we keep it in a separate branch until it's complete?

NightEule5 avatar Jan 10 '22 08:01 NightEule5

Ok, I've refactored the node tree a bit and created low-level file/string writing classes, and tests still pass. Should I create a pull request to the main branch or should we keep it in a separate branch until it's complete?

@NightEule5 could you please create a PR to this repo to main? may be I can help with some review..

orchestr7 avatar Jan 10 '22 08:01 orchestr7