Improve integration #1
Conversation
style: run `swiftformat`
| public var isPersistent: Bool? | ||
| public var isRequired: Bool? | ||
| public var requiresEquals: Bool? | ||
| public var repeatCount: RepeatCount? | ||
| public var isRepeatable: RepeatCount? |
There was a problem hiding this comment.
I'd intentionally renamed some of these properties on the Swift side to be more idiomatic -- but I do see the benefit of keeping the original names, to avoid the need for CodingKeys. As a workaround, perhaps we could (taking this specific case as an example) make isRepeatable a private property and create a public repeatCount with a computed getter and setter that simply forward to isRepeatable?
There was a problem hiding this comment.
Well, FigSpec should be a swift representation of the FigSpec so IMHO we should align with those property names.
There was a problem hiding this comment.
hmm I'd say that we should be sticking to Swift's API design guidelines to keep the library idiomatic. To motivate this, consider for example a hypothetical Python library with Fig bindings: I think it'd unambiguously be better to use snake case there in order to adhere to the language's guidelines. The situation is less extreme with Swift but it's in the same spirit imo.
| @@ -158,12 +162,12 @@ public struct FigSpec: Encodable { | |||
| } | |||
| } | |||
|
|
|||
| public var names: [String] | |||
| public var arguments: [Argument]? | |||
| public var name: [String] | |||
There was a problem hiding this comment.
I wonder whether we'd benefit from an ExpressibleByArrayLiteral & ExpressibleByStringLiteral type here so that users could do either of name = "Foo" or name = ["Foo", "Bar"]
There was a problem hiding this comment.
Yeah it would be a nice tweak, but I am not sure that's possible.
There was a problem hiding this comment.
afaik it's possible; you can make a type conform to both aforementioned protocols and it should work out of the box.
|
I was also thinking of making |
|
I also thought about using a subcommand but unfortunately there are some rough edges with that approach – for example, if the root command has a body, it takes precedence over subcommands, and fixing that would require that users refactor the structure of their tool. Since our current approach relies on an |
CodingKeysenums from FigSpec structs