You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 8, 2023. It is now read-only.
archivedArchived because of inactivityiOSMapbox Maps SDK for iOSmacOSMapbox Maps SDK for macOSrefactorSwiftSpecific to the Swift/Objective-C bridge on iOS or macOS
For the most part, the method names we’ve chosen in Objective-C make sense in Swift as well. However, there are some cases where the method name feels more verbose than usual, especially when the name describes a parameter’s type in addition to its role.
We should audit the entire API for opportunities to make Swift code read better. Now that realm/jazzy#136 has made it into our build system, we can annotate APIs with NS_SWIFT_NAME where they provide some measure of relief for Swift coders. For example, in #5110, visibleFeaturesAtPoint(_:inStyleLayersWithIdentifiers:) becomes visibleFeatures(at:styleLayerIdentifiers:), consistent with the Swift API design guidelines.
Considering the widespread changes that will be made to Foundation class naming in Swift 3, we should take care of this work around the time people are upgrading to the upcoming release of Xcode, so our changes won’t be breaking changes relative to the language itself.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
archivedArchived because of inactivityiOSMapbox Maps SDK for iOSmacOSMapbox Maps SDK for macOSrefactorSwiftSpecific to the Swift/Objective-C bridge on iOS or macOS
For the most part, the method names we’ve chosen in Objective-C make sense in Swift as well. However, there are some cases where the method name feels more verbose than usual, especially when the name describes a parameter’s type in addition to its role.
We should audit the entire API for opportunities to make Swift code read better. Now that realm/jazzy#136 has made it into our build system, we can annotate APIs with
NS_SWIFT_NAME
where they provide some measure of relief for Swift coders. For example, in #5110,visibleFeaturesAtPoint(_:inStyleLayersWithIdentifiers:)
becomesvisibleFeatures(at:styleLayerIdentifiers:)
, consistent with the Swift API design guidelines.Considering the widespread changes that will be made to Foundation class naming in Swift 3, we should take care of this work around the time people are upgrading to the upcoming release of Xcode, so our changes won’t be breaking changes relative to the language itself.
/cc @friedbunny @boundsj @tmcw
The text was updated successfully, but these errors were encountered: