We strive for 99% language and feature compatibility, but due to the nature of the platforms and underlying runtimes, a small handful of features will not be available on all platforms, and a few platform-specific features are provided that don't make sense on the other platforms.
The following table marks the core points of differentiation between the different Compiler Backends
|Feature||Echoes (.NET)||Cooper (JVM)||Toffee (Cocoa)||Island|
|Lifecycle Management||GC||GC||ARC||ARG & GC*|
|Pointers & Direct Memory Access||In Unsafe Mode||No||Always||Always|
|Generics||Full Support||Type-Erased||Type-Erased||Full Support|
|Aspects||Write & Use||Use||Use||Use|
Also read in more detail about edition-specific language features:
- Language features specific to | | |
Garbage Collection vs. ARC
On Island projects targeting the Cocoa platform, both GC and ARC are used, the former for Island-native objects, and the latter for Objective-C Runtime-based Cocoa objects ands Swift objects. Please refer to the Object Models topic for more details.
In most code scenarios, GC and ARC will behave pretty comparably, and code written that deals wit object references generally will look the same — i.e. will not worry about explicitly freeing object memory. There are however some subtle differences, in particular when it comes to dealing with retain cycles, which GC has no problem resolving, but that can cause leaks in ARC. Special Storage Modifier keywords ,
strong (implied by default),
unretained, are provided to help with this on the Cocoa platform (and will be ignored on .NET and Java). In C# these three keywords start with two underscores.
Also unique to ARC, a keyword is provided to manually instantiate additional auto-release pools, where needed. This is seldom the case, but might be necessary in some specific cases. The topic on ARC will go into this in more detail.
- Storage Modifier for ARC
- Auto-release Pools for ARC
- Object Models for Island/Darwin
- Automatic Reference Counting vs. Garbage Collection. See also Automatic Reference Counting vs. Garbage Collection
Blocks (a.k.a. .NET Delegates)
types, i.e. method references (also called
delegates), are supported on on all platforms, but there are some limitations.
block keyword is provided on all platforms, and synonymous with the now deprecated
delegate keyword (refer to the Blocks topic for reasons for this change).
Oxygene has support for inline block types in method or property declarations. This syntax is supported on all platforms, but limited to block signatures that match an existing
Func delegate signature on .NET.
Note that on Cocoa, the
method keywords will declare C-level when used for block type declarations, rather than true Objective-C blocks (i.e. C's
* syntax opposed to
^ block syntax). Only the
delegate keywords declare true Objective-C blocks. (On .NET and Java, all 5 keywords behave the same way.)
Since on .NET and Java it has never been recommended to use
method for block declarations, it is recommended to consistently stick to
[[block (keyword)|block]] for cross-platform code.
Note: For RemObjects C#, this equally applies to
delegate types. Inline
delegate type declarations are permitted. On all languages, the
FunctionPointer Aspect can be applied to mark a delegate as a function (and not a block) pointer in C#.
C Runtime Heritage and Influences on Elements for Cocoa
Due to it being built on the Objective-C runtime, which itself is a true superset of standard C, Oxygene on Cocoa and Island-backed platforms gains support for a wide variety of concepts from the C language, not the least of which being access to the vast C runtime library, with
printf() and thousands of other well known functions, records and types. Due to C being inherently non-object-oriented, this means Oxygene for Cocoa provides access to non-OOP libraries and functionalities in a manner that would have been deemed "unacceptable" on the strictly-OOP .NET and Java platforms.
Examples of these are more liberal use of pointers and reference parameters, global constants and functions, and the more traditional method-lesstypes.
For the purpose of cross-platform code, this is mainly irrelevant, as such code can (and should) stick to using the higher-level OOP based features and functionality.
Aspects & Custom Attributes
Custom Attributes are supported on all platforms, but are more limited in scope on Cocoa and Island. Querying for custom attributes at runtime currently relies on platform-specific APIs (provided by the platform on .NET and Java, and by libToffee on Cocoa and Island RTL), but a higher-level cross-platform abstraction is available as part of Elements RTL's Reflection APIs.
The standard attribute syntax with square brackets (
) in Oxygene and C#, the at symbol (
@) in Swift and Java and angle brackets (
<>) in Mercury is also supported to specify a limited range of Special Attributes defined by the compiler. These special attributes are not backed by classes.
Attributes and Aspects are not supported by the Go language.
Cirrus (Implementing Aspects)
The compiler supports applying aspects on all platforms. But Since aspects essentially run as part of the compiler, aspects can be written using in .NET (Classic and .NET Standard 2.0), no matter the target platform. Aspects can be created so that they are platform-independent and can be applied to any of the four platforms. In fact, that is the default behavior.
Miscellaneous and Minor Differences
- semantics differ between .NET, Java and Cocoa.
- Nullable Types, like boxing, have some limitations on Cocoa (namely that they support only numerical values, and no ).
- support differs on Cocoa, with the availability of non-object Open and Static Arrays.
- As part of ARC, Storage Modifiers are supported on Cocoa only.
- Interfaces/Protocols support
optionalmembers, on Cocoa.
dynamictype is only supported on .NET and Cocoa, and on the latter maps to
idtype and provides sightly different usage semantics.
unsafecode is not supported on Java, and all code is assumed to be
unsafeon Cocoa and Island, making the keyword ignored/unnecessary on that platform.
- Generic co/contra-variance is supported on .NET only.
- Differences in [Pointer References in Oxygene for Cocoa](Pointer References in Oxygene for Cocoa).
externalkeyword is supported on .NET (P/Invoke) and Java (JNI), but not applicable on Cocoa.
- Parallel "for" loops, parallel sequences and queryable sequences are currently only supported for .NET.
- Special Java-style exception handling extensions will be a new platform difference, once implemented.
- Garbage Collection, also see ARC vs GC
- Parallel For Loops in Oxygene
- Parallel Sequences in Oxygene
- P/Invoke and the
- implementing Aspects with Cirrus
- ARC & Auto-Release Pools, also see ARC vs. GC
- Constructors map to/are interchangable with
- Storage Modifier –
unretainedor variations of them
- Bridging via
- Optional interface/protocol members
- Garbage Collection, also see ARC vs GC
- Java Native Interface (JNI) and the
- Unsigned Integers are not supported by the Java runtime, but get emulated by the compiler