Skip to content
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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add multi line array options #838

Open
wants to merge 2 commits into
base: v2
Choose a base branch
from

Conversation

rasta-rocket
Copy link

Hi @pelletier 馃憢

It has been a while since my last PR #578 on this repo.

Well the goal here is to re add that feature in the v2 of go-toml and especially tomll

Explanation of what this pull request does.

The goal of this PR is to add a flag to the linter that allow us to render the TOML file with multilines array (meaning one line by element)

Don't hesitate if you need more details

Cheers 馃槈


Paste benchstat results here

Copy link
Owner

@pelletier pelletier left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the pull request! and sorry it took me so long to get back to you.

I'd like to see if we can use a closure around each program's processing function to handle arguments locally instead of a generic way of passing options.

@@ -12,14 +12,17 @@ import (
"github.com/pelletier/go-toml/v2"
)

type ConvertFn func(r io.Reader, w io.Writer) error
type Options map[string]interface{}
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For now I'd like this to be a struct, to lean on go's default values to avoid exists/empty checks and casting, and make it easier to understand which options are supported.

Because Program is used by multiple programs, a single Options struct may be unlikely to work with all of them. I think the easiest way around this is to have convert() take an options struct, and return a function, creating a closure around the provided options. That way each program can build its own options an generate its own processing function, without the need for a one-size-fits-all options type.

@pelletier pelletier added the feature Issue asking for a new feature in go-toml. label Feb 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Issue asking for a new feature in go-toml.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants