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

CLLocationCoordinate2D conformance to Codable should be private #84

Closed
1ec5 opened this issue Dec 18, 2019 · 0 comments · Fixed by #96
Closed

CLLocationCoordinate2D conformance to Codable should be private #84

1ec5 opened this issue Dec 18, 2019 · 0 comments · Fixed by #96
Assignees
Labels
backwards incompatible changes that break backwards compatibility of public API op-ex Refactoring, Tech Debt or any other operational excellence work.
Milestone

Comments

@1ec5
Copy link
Contributor

1ec5 commented Dec 18, 2019

Turf publicly declares CLLocationCoordinate2D’s conformance to Codable and implements the protocol according to the GeoJSON standard, as an array in longitude, latitude order. But this is problematic if the application or some other library needs to support some other coordinate representation in JSON. For example, Overpass JSON represents coordinate pairs as objects. Turf needs this Codable implementation but doesn’t need to export it publicly. It would be trivial for client code to reimplement this conformance if necessary.

extension CLLocationCoordinate2D: Codable {
public func encode(to encoder: Encoder) throws {
var container = encoder.unkeyedContainer()
try container.encode(longitude)
try container.encode(latitude)
}
public init(from decoder: Decoder) throws {
var container = try decoder.unkeyedContainer()
let longitude = try container.decode(CLLocationDegrees.self)
let latitude = try container.decode(CLLocationDegrees.self)
self.init(latitude: latitude, longitude: longitude)
}
}

/cc @mapbox/navigation-ios @frederoni

@1ec5 1ec5 added op-ex Refactoring, Tech Debt or any other operational excellence work. backwards incompatible changes that break backwards compatibility of public API labels Dec 18, 2019
@1ec5 1ec5 added this to the v1.0 milestone Dec 18, 2019
@JThramer JThramer self-assigned this Jan 7, 2020
@Udumft Udumft self-assigned this Mar 25, 2020
@Udumft Udumft closed this as completed in #96 Apr 2, 2020
@1ec5 1ec5 modified the milestones: v1.0.0, v0.4.0 Jun 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backwards incompatible changes that break backwards compatibility of public API op-ex Refactoring, Tech Debt or any other operational excellence work.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants