For Swift 3.0, Apple applied a great many changes to how Cocoa APIs appear to Swift.
Although we see RemObjects Swift as a "Swift for Cocoa" and have Swift (like the other Elements languages) be much more native to the Objective-C runtime than Apple's Swift, we still wanted to make these renamed APIs available to RemObjects Swift users, as well.
We have done so as of Elements 9.0, in a way that we hope will be nice and intuitive.
The "Grand Rename", as Apple refers to it, consists of several separate aspects that contribute to new names and different APIs to appear to the Swift language when working with Cocoa. The rename has no effect on RemObjects Swift on the other platforms (.NET, Java/Android and Island), as it only affects the types imported from Objective-C.
NS Prefix from Foundation types.
For all types in Foundation, the
NS prefix is being removed.
NSString becomes just
String (which of course always has been an alias in Elements),
NSIndexPath becomes just
IndexPath, and so on.
While for Apple's compiler, this is a breaking change, in Elements we decided to just make these types available under both names. So the
NS* versions will continue to work in your existing code, but you can start using the names w/o prefix when writing new code.
This change applies to all languages, so Oxygene and C# will see the new type names without
NS prefix, too. For Swift, Code Completion will default to only show (i.e. recommend) the new names, while for Oxygene, C# and our new Java Language front-end, CC will continue to recommend the "real" Cocoa names, with
Note that this renaming only affects Foundation, and only the
NS prefix. Other framework prefixes will remain; in particular AppKit classes on macOS will continue to have
NS prefixes, and – for example – UIKit classes on iOS will continue to have
UI* prefixes, as in
UIView and so on.
- See (SE-0086) Drop NS Prefix in Swift Foundation.
Rename Methods and Omit Needless Words
In addition to renaming the core types in Foundation, Swift 3.0 also prescribes a thorough renaming of many Cocoa method (and property) names, to make them less verbose and fit in better with Swift naming guidelines (see SE-0023).
This encompasses dropping redundant nouns and prepositions from method names, shortening them, and also converting parts of some method names into first parameter prefixes.
public static func bezierPathWithRect(_ rect: CGRect!) -> instancetype!
public static func bezierPath(with rect: CGRect!) -> instancetype!
Note how the
Rect noun has been dropped, because it is redundant with the
CGRect type name, and how
with has been moved into the parenthesis, and is now naming the first parameter.
This renaming follows rather complex rules outlined in SE-0005, and is applied to all Objective-C classes imported with FXGen, including the platform
.fx files we ship with Elements 9.0 and later, as well as any custom Objective-C libraries of frameworks you import yourself using the new version of the tools.
This change applies only to the Swift language, while Oxygene, C# and Java continue to see members with their original Cocoa notations. For backward compatibility, the original Cocoa names can also still be called from Swift, but they will no longer be offered by Code Completion, and new Swift code should adopt the new names.
- See (SE-0005) Better Translation of Objective-C APIs Into Swift
Grand Central Dispatch (GCD,
The Grand Central Dispatch APIs, previously available via C-level
dispatch_ functions, have been wrapped in a new class structure that is more intuitive to use from Swift. This is provided as wrapper classes in Swift Base Library, and the original C APIs continue to be available as well.
This new wrapper is available to all languages when referencing
libSwift, but it is (currently) only available on the Cocoa platform (as is the underlying GCD API).
- See (SE-0088) Modernize libdispatch for Swift 3 naming conventions
Not Implemented (yet)
The following renaming proposals are not implemented yet for Elements 9.0 and under review for a future update: