By default, class and interface types on the Island platform are native Island types, adhering to Elements' own object model created specifically for Island. Class types will descend from
System.Object or one of it's descendants, forming a single tree of classes.
On some Island sub-platforms, additional, platform-native object and/or interface models are supported. Classes or interfaces defined using these models adhere to a different object model, and live in their own class hierarchy, with classes typically descending from a root object class provided by the platform.
Darwin sub-platform for Cocoa, two additional object models are (or will be) supported, in addition to native Island classes. These models are available both for classes and interfaces
- Island – native Island objects and interfaces.
- Cocoa – Objective-C objects (descending from
Foundation.NSObject) and protocols.
- Swift – Native Swift objects (descending from
Swift.Object) and protocols.
The Darwin sub-platform provides full support for the Objective-C class model, as needed to interact with the core Cocoa APIs from Foundation over AppKit/UIKit to more specialized frameworks provided by Apple and third parties.
All Cocoa classes descend (directly or indirectly) from
Foundartion.NSObject. Classes declared in code will automatically become Cocoa classes, if they descend from a Cocoa class. For classes without an explicit ancestor, the
@Cocoa Aspect can be applied to mark a class as belonging in the Cocoa hierarchy (it will then descend from
Foundation.NSObject instead of
Once Apple Swift reaches ABI stability (promised for later in 2019), the
Darwin sub-platform will also gain support for consuming and extending classes implemented in Apple's Swift dialect, and directly participating in Apple Swift's object model. Swift objects will form a third class hierarchy.
Note: this is not to be confused with using the Swift language dialect provided by Silver. As with all four Elements languages, classes written in Silver can be native Island classes, Objective-C Runtime classes or, optionally, Swift Runtime classes.
Mixing Object Models
Objects and interfaces from the different object models can freely interact with each other. Classes declared in one model may have fields, properties or method parameters of the other model, and the interaction will work seamlessly as one would expect.
The same interfaces can be implemented by classes of either model, allowing code to interact with the types without needing to be aware of the underlying class model – even though the classes themselves do no share a common ancestor. Similarly, Island-native generics can be used with classes or interfaces of either model, seamlessly and without runtime overhead (e.g. an Island-native
List<T> may be instantiated to hold Cocoa objects, Island Objects or Swift objects).
Automatic wrapping and unwrapping will happen when assigning objects to a base
NSObject-type variable of a different object model, using wrapper classes provided by Island RTL, such as
CocoaWrappedIslandObject et al, but this will rarely affect strongly typed user code.
Default Object Model
As indicated above, the default object model for classes and interfaces normally is the native Island object model, and classes and interfaces without ancestor will become part of this model.
A new "Default Object Model" Compiler Option is provided to change that. By setting this option to "Cocoa", classes and interfaces declared without ancestor will become Objective-C types by default instead, making the compiler behave much like the classic Cocoa platform, where all classes were based on the Objective-C runtime.
This option is useful when writing code that is highly Cocoa-centric (such as macOS or iOS GUI apps), and best used with the New Cocoa Mode that provides additional compatibility with classic Cocoa projects.
Of course Cocoa classes in this mode can still freely interact with native Island types and Swift Runtime types, as described in the previous section.
Similarly, once Apple Swift reaches ABI and Module stability, the Default Object Model can be set to "Swift" in order to have classes and interfaces default to being based on the Apple Swift Runtime, instead.
Setting a default object model also brings the
ObjectModel namespace intio scope (where
ObjectModel is the actual name, e.g.
RemObjects.Elements.System.Cocoa. This is how Common standard type named (mainly
Exception) get mapped to their appropriate model.
On the other sub-platforms, all classes are native Island objects.
While mostly useful on the Windows sub-platform, but Interface types on any Island sub-platform, optionally, be cdeclared as COM-compatible interfaces for interaction with other COM-compatible environments.
Interfaces are native Island (or Cocoa) interfaces by default. If an interface is declared to descend (directly or indirectly) from
IUnknown, it automatically becomes a COM-compatible interface. Alternatively, it can also be marked with the
@COM Aspect (and will then automatically descend from
Please refer to the COM topic for more details.