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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Geometric types should conform to common protocol that converts to Geometry #158

Closed
1ec5 opened this issue Sep 29, 2021 · 3 comments · Fixed by #159
Closed

Geometric types should conform to common protocol that converts to Geometry #158

1ec5 opened this issue Sep 29, 2021 · 3 comments · Fixed by #159
Assignees
Labels
improvement Improvement for an existing feature.
Milestone

Comments

@1ec5
Copy link
Contributor

1ec5 commented Sep 29, 2021

GEOSwift defines a GeometryConvertible protocol that makes it possible to initialize a Feature without redundantly specifying both the Geometry case and the geometric type’s initializer at the same time. Turf’s GeoJSONObject and Geometry enumerations should have something similar. For example:

var geoJSON = Feature(geometry: .point(Point(coordinate)))

would become simply:

var geoJSON = Feature(geometry: Point(coordinate))

It’s similar to the initializers and literals that #154 added to JSONValue, but this protocol distributes the implementation across each type:

/// Initializes a JSON value representing the given Boolean value.
public init(_ bool: Bool) {
self = .boolean(bool)
}

/cc @macdrevx

@1ec5 1ec5 added the improvement Improvement for an existing feature. label Sep 29, 2021
@1ec5 1ec5 added this to the v2.1 (beta) milestone Sep 29, 2021
@1ec5
Copy link
Contributor Author

1ec5 commented Sep 29, 2021

A similar JSONValueConvertible protocol might eliminate a major backwards-incompatible change that arose in #154, making both syntaxes equivalent again:

feature.properties = [
    "literal": "Jason",
    "non-literal": .string(name),
]
feature.properties = [
    "literal": "Jason",
    "non-literal": name,
]

@1ec5
Copy link
Contributor Author

1ec5 commented Sep 30, 2021

A similar JSONValueConvertible protocol might eliminate a major backwards-incompatible change that arose in #154, making both syntaxes equivalent again

I’ve been trying various gymnastics but haven’t managed to make this work without making [String: Any?] conform to ExpressibleByArrayLiteral, which would be overbroad.

@1ec5
Copy link
Contributor Author

1ec5 commented Oct 5, 2021

A similar JSONValueConvertible protocol might eliminate a major backwards-incompatible change that arose in #154, making both syntaxes equivalent again

Now tracking this feature separately in #163.

@1ec5 1ec5 closed this as completed in #159 Oct 6, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
improvement Improvement for an existing feature.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant