Object Models

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.

Right now, additional object models are supported on the Darwin (Cocoa) and Windows sub-platforms.


On the 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](/API/Aspects/ObjectModels) can be applied to mark a class as belonging in the Cocoa hierarchy (it will then descend from Foundation.NSObject instead of System.Object.

Once Apple Swift reaches proper and documented ABI stability, 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 ABI). 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 five OOP 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 Object/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.

Standard Types

Setting a default object model also brings the RemObjects.Elements.System.ObjectModel namespace intio scope (where ObjectModel is the actual name, e.g. RemObjects.Elements.System.Island or RemObjects.Elements.System.Cocoa. This is how Common standard type names (mainly Object, String and Exception) get mapped to their appropriate model.

In C#, the object and string keywords will map to whatever Object or String type is thus in scope.

Other Sub-Platforms

On the other sub-platforms, all classes are native Island objects.


While mostly useful on the Windows sub-platform, Interface types on any Island sub-platform can, 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 IUnknown).

Please refer to the COM topic for more details.

See Also