[Estimated Reading Time: 5 minutes]

In the periodic table of the elements, at #9 we find Fluorine. Curiously though the name “Fluorine” is not used (that I am aware of) anywhere in the Elements 9.0 release which dropped this week. But there is plenty of interest in this release, aside from Period Table curios.

I’m busy working an ASP.NET MVC/WebApi Azure project (using Oxygene) for which I am using one of the more recent 8.x beta’s and haven’t had chance to look at 9.0 in detail specifically yet so I shan’t be covering everything. Some of the features have been in the recent beta’s – in some cases for some time – so I can talk about those with some experience to relate to.

For detailed coverage of every aspect of this new release you can of course go to the source but in the meantime here’s my whistle-stop tour of the key highlights.


If you aren’t already aware, the Elements compiler stack is a sophisticated beast with different “front-ends” (the source languages you write your code in) all paired to the same team of “back-ends” (the target platforms your source code can be compiled, natively, to run on).

Island is a new back-end. In fact, it is apparently going to become a collection of back-ends, with two platforms incorporated thus far and potentially more to come. The two supported as of Elements 9.0 are:

  • Win32 (incl. Win64)
  • Linux

That’s right. As well as the long-standing support for the .NET platform for Windows, the Elements compiler can now produce Win32/Win64 native x86 executables developed directly against the Win32 API’s.

I have yet to look at the Win32 support in depth, and Linux is not an area I have any exposure to so am unable to provide detailed commentary on that score. But this raises some tantalising prospects as I am sure are already perhaps beginning to occur to some.

Somewhat related is the introduction of a Delphi compatibility library (although this is still a work in progress, as mentioned in the wiki). The Oxygene compiler has always had some limited support for Delphi specific language foibles such as different keywords for functions and procedures (rather than simply methods which either do or do not have return values). But since development occurs in the context of the specific target platforms involved, Delphi compatibility at that level has been something you mostly had to put in place for yourself, if you wished.

The new Delphi compatibility library intends to address that. Whether you choose to use it of course is still up to you. 🙂

But back to the native Win32 platform support, remember this isn’t limited to just ObjectPascal development using Oxygene but also extends to the C# and Swift front-ends also (and if polyglot programming is your thing, there’s no reason to not mix and match as you see fit).

Develop x86 native Windows applications (or .NET or Java/Android for that matter) using Swift ? I wonder if Apple ever had that in mind ? 🙂

Speaking of the language front-ends, Elements 9 also introduces (in “coming soon” form at this stage), Iodine.


This is the name for RemObjects implementation of Java. That’s Java the language, as distinct from (the well established and proven support for) Java the platform, with their existing front-end languages.

Although not part of the initial release version of Elements 9, Iodine is already in beta and so is available to all current subscribers (no limited access beta programs with RemObjects).

Oxygene Continues to Evolve

With all this development of new back-ends and front-ends, you might be forgiven for expecting there to have been little development on the existing components in the stack.

Nothing could be further from the truth, as Oxygene continues to evolve and develop as a language.

One thing that I was initially skeptical of was the introduction of Unified Class Syntax. The name of the feature is not especially descriptive imho since the feature operates at the level of a unit, not a class specifically, although classes in units are of course the most affected. So I’ll just call it Unified Syntax (which will also save me some typing).

In a nutshell, Unified Syntax eliminates the use of separate interface and implementation sections in a unit, essentially making things much more C#-like.

Sometimes I think this is a step backward. With classes with more than a handful of methods, having that “table of contents” in the interface section makes living with the code in the longer term far more comfortable. Changes that introduce or remove methods are more readily apparent when doing diff’s etc, as these are reflected in that table of contents very visibly, as well as being often buried (or at least not so clearly identifiable) in the (sometimes large) chunks of changes going on down in the implementation section.

But, all that structure is undeniably cumbersome when it comes to things like a POCO (Plain-Ol’ CLR Objects). Or, if you are implementing a simple class which overrides a method or two and adds some properties, such as extending an ASP.NET IdentityContext class.

With Unified Syntax these become -(dare I say it ? Yes I think I dare…)- quite beautiful. 🙂

Example of a POCO:

namespace MyProject.ViewModels;

    Person = public class
      property Id: String;
      property FirstName: String;
      property LastName: String;
      property DateOfBirth: DateTime;


The removal of interface and implementation in these cases doesn’t exactly shake the Earth to its core, but for me at least this is a case of not realising quite how much noise there was until it was gone. Like when the air-conditioning goes off when you stay late in the office. You were glad it was keeping you warm/cool during the day but sometimes that unexpected extra peace and quiet you didn’t realise was possible is a surprisingly welcome relief.

Now for something where the changes are more significant: A class with a trivial overridden ctor as well as some additional properties:

namespace MyProject.Repository;


    MyDbContext = public class(IdentityContext<IdentityUser>)

      property Customers: DBSet<Customer>;




As I say, I was initially skeptical about Unified Syntax but the great thing is that the compiler seamlessly adapts to whichever style you have adopted in each unit. There are no compiler switches or directives to contend with, you simply choose whether to use interface and implementation sections in your unit or not, according to which you are most comfortable with either in that particular case or generally.

The only thing you cannot do is mix and match in the same unit. That is, you cannot have interface/implementation sections and then go ahead and implement a method in the interface section.

Essentially, I suppose, the presence (or absence) of the interface keyword itself (immediately following the namespace declaration) is the switch/directive, if you want to think of it like that.

Correction: You can even mix and match styles.

To have the ability to mix-and-match the one pre-requisite is that your unit has interface and implementation sections. That being the case, you can then choose (on a method-by-method basis, if you wish) to inline a method implementation in the class declaration, or simply declare a method and then provide the implementation in, well, the implementation section.

You might for example choose to inline trivial methods (one-liner cases) whilst separating more complex method bodies into the implementation section. Or you might have two (or more) classes in the unit and wish to use Unified Syntax for some but not others.

For some reason I had thought this wasn’t possible (or perhaps just not desirable) but ran into a situation where it would be useful and tried it. I’ll provide details of that scenario in a follow-up post.

Likewise I shall try to find time to post on more of the new features in Elements 9.0 as they occur to me and/or I gain familiarity with them.

For now I must back to that ASP.NET project (which should provide some blog-able material itself shortly).

9 thoughts on “The 9th Element”

  1. Both Delphi and Swift use ARC to some degree. Borland (in Delphi 8) tried to introduce garbage collected environment, it was completely alien and slow, and so Delphi.NET died. Apple introduced traced garbage collection as an optional feature, but soon disappointed and deprecated it. IIUC RemObjects had no better idea than to introduce TGC, but dared to call that thing Swift. No, dear, authentic Swift is ARC only.

    Given that Apple Swift is open sourced, I guess Apple assume it might be ported to Windows eventually.

    1. The death of Delphi.NET had nothing to do with GC. The GC was fundamental to .NET (you may have noticed that C# hasn’t died, despite having precisely the same GC as Delphi.NET). No, Delphi.NET died because Borland tried to make .NET code single-source compatible with VCL code and as a result it was neither as good as Delphi.Not.NET nor as good as Delphi.NET could have been (which actually is precisely why Oxygene even exists! RemObject saw what Borland did and decided they could do better. And how!)

      It was .NET that provided the GC, just as Java and other platforms provide GC. RemObjects languages target those platforms natively so the GC you get in each case is the GC of the platform. Whichever Elements language you use, when targeting .NET and Java, you are using GC and when targeting Cocoa, you are using ARC. The RemObjects implementation of ARC is described as having some subtle differences as compared to the Objective-C implementation of ARC.

      RemObjects’ Swift uses ARC on Cocoa, as do Oxygene and C#, aiui. But Swift on .NET and Java use GC.

      For the new native x86 platforms (Island) I believe a GC is incorporated in the RTL in that case.

      1. Yeah, Delphi should have introduced total ARC and weak references long ago, that would be more interchangeable with TGC compared to current single-reference limitation.

        C# is not a fair experiment since there is no normal C# to compare it with broken C# as it exists currently. So we can’t determine the damage of TGC in C#. We can only make rough performance comparisons of Mac OS X where ARC dominates to performance of Windows 10 where there is too much .NET hype during the last years. We can also compare Android with iOS. WIndows 10 is slower and more RAM-consuming since Seven times. Android is widely known to drain battery faster than iOS and BlackBerry OS based on QNX. For me, that is correlated. Everytime we have TGC and ARC, ARC wins. Tools only providing TGC are hopelessly broken, and you’ll never be able to write slim programs with it. This article is all about how developers are wrestling with unsolicited TGC.

        Speaking about the fairness, first, there is Javolution project translating Java to C++. I have investigated it, there is only a reference counter there. No DRC, no cycle collector like in XPCOM and Nim, just plain reference counter. And Javolution project page mentions several projects ported to native using Javolution. Java developers live with ARC pretty fine.

        So I am making a statement that TGC in Java and C# is a forced feature, not what developers asked for (or, at least, not quite every developer). If you are restricted to Microsoft ecosystem, you only have awful C++ (where RC is possible via COM, but surprisingly unconvenient for any experienced Delphi developer). It’s a pity most developers previously saw RC in C++ only. Another options are comparably incapable VB, VBScript, JScript. And, finally, VB.NET, J#, JScript.NET and C#. Generally, one just has no choice. Developers use TGC just because .NET forces so, not because of their conscious well-thought decision (like a compiler flag in Objective-C 2.0). But there is a light in the end of this tunnel too: C++/CX! Microsoft created a whole new compiler with ARC as opposed to TGC in the previous C++/CLI compiler.

    1. I haven’t looked at the Delphi RTL library yet but the RTL is only a tiny part of the challenge of compiling “Delphi code”. There’s the VCL as well, which is a whole different and more significant body of work.

Comments are closed.