This page collects an overview of the few subtle differences for the Elements compiler, and the Oxygene, RemObjects C# and Swift languages on the three different platforms (.NET, Cocoa and Java). We strive for 99% language compatibility, but due to the nature of the platforms and underlying runtimes, a small handful of language 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.
Garbage Collection vs. ARC
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 the Cocoa platform, the 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.
Blocks (a.k.a. .NET-Style Delegates)
Blocks, that is method references, are supported on all platforms, but there are some limitations.
The compiler supports inline block types in method or property declarations. This syntax is fully capable on Cocoa, but limited to block signatures that match an existing .NET Framework
Func delegate signature on .NET. On Java, inline block syntax is not supported. The solution for cross-platform code is to use explicit block type declarations.
In Oxygene, the
block keyword is provided in all three editions, and synonymous with the now deprecated
Note that in Oxygene for Cocoa, the
method keywords will declare C-level Function Pointers 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 for cross-platform code.
For RemObjects C# and Swift, this applies equally to
delegate types. Inline delegate type declarations are permitted. Because C# does not use
different keywords like Oxygene does, the
[FunctionPointer] Attribute can be applied to mark a delegate as a function (and not block) pointer in C# and Swift.
C Runtime Heritage and Influences on Elements for Cocoa
Due to its being built on the Objective-C runtime, which itself is a true superset of standard C, Oxygene for Cocoa gains support to 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-less Record or Struct types.
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.
Custom Attributes are supported on all platforms as of Elements 8.3, but are more limited in scope on Cocoa. 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, but a higher-level cross-platform abstraction is available part of Elements RTL's Reflection APIs.
The standard attribute syntax with square brackets (
) in Oxygene and C# and the at symbol (
@) in Swift is also supported to specify a limited range
of Special Attributes defined by the compiler. These special attributes
are not backed by classes.
Aspects / Cirrus
As of Version 6.2, the compiler supports applying aspects on all platforms.
Since aspects essentially run as part of the compiler, aspects continue to be written using .NET (and for .NET, 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.
As of Elements 7, properly named aspects (with the
*Aspect class name suffix) can be applied like regular attributes
on all platforms, no longer requiring the
Miscellaneous and Minor Differences
- semantics differ between .NET, Java and Cocoa.
- Arrays support differs on Cocoa, with the availability of not-object-based open and static arrays.
- As part of ARC, Storage Modifiers are supported on Cocoa only.
unsafecode is not supported on Java, and all code is assumed to be on Cocoa making the keyword ignored/unnecessary.
- Generic co/contra-variance is supported on .NET only.
- There are differences in how Pointer References work on 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).
BigIntegeris currently only supported for .NET. Support for Java & Cocoa is under review for a future update.