-
-
Notifications
You must be signed in to change notification settings - Fork 529
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Support encoding comments and specifying the encoding format
This allows encoding comments and setting some flags to control the format. While toml.Marshaler added in #327 gives full control over how you want to format something, I don't think it's especially user-friendly to tell everyone to create a new type with all the appropriate formatting, escaping, etc. The vast majority of of use cases probably just call in to a few simple categories such as "use `"""` or "encode this number as a hex". I grouped both features together as they're closely related. What I want is something that: 1. works well with other encoders/decoders; 2. allows setting attributes programmatically; 3. supports round-tripping by default on a standard struct; 4. has a reasonable uncumbersome API. Most options (custom types, struct tags) fail at least one of these. --- This adds two new methods to Encoder: the Comment() method just sets a comment for a key, and the FormatAs() method sets the format. A simple example: err := toml.NewEncoder(os.Stdout). FormatAs("multi_line", toml.AsMultilineString). FormatAs("single_line_raw", toml.AsLiteralString). Comment("comment_me", "Well, hello there!"). Encode(someStruct) This way, pretty much any flag can be added programmatically without getting in the way of JSON/YAML/whatnot encoding/decoding. The idea behind the naming here is that you can have one `As*` hint, with one or more `With*` hints. --- I don't especially care how you need to pass the keys as strings, but there isn't really any good way to do it otherwise. I'm not necessarily opposed to also adding struct tags for most of these things, although I'm not a huge fan of them. Since struct tags can't be set programmatically it's not really suitable for many use cases (e.g. setting comments dynamically, using multiline strings only if the string contains newlines, etc.) It's something that could maybe be added in a future PR, if a lot of people ask for it. Not entirely sold on the API; you have a fairly large list of variables you can add to FormatAs() and many are invalid (e.g. they apply only for some types). Maybe it's better to split it out to FormatString(), FormatNumber(), etc. and add `type formatString`, `type formatNumber`? Another thing not covered here is proper round-tripping; e.g. decoding a TOML file and encoding it again will make it lose the comments. We already have a `MetaData` object when decoding, so it's probably better to add all the information there, and allow passing that to the encoder (or something?) Need to think about comments especially, since not every comment is necessarily associated with a key Fixes #64 Fixes #75 Fixes #160 Fixes #192 Fixes #213 Fixes #269
- Loading branch information
Showing
4 changed files
with
111 additions
and
17 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters