The 9th Element

[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.

Island

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.

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;

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

end.

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;

  uses
    Microsoft.AspNet.Identity.EntityFramework,
    MyProject.Models;


  type
    MyDbContext = public class(IdentityContext<IdentityUser>)

      property Customers: DBSet<Customer>;

      constructor;
      begin
        inherited("name=MyConnectionString");
      end;

    end;

end.

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).