Coding Conventions and RemObjects Elements

One of the most distinguishing features of RemObjects Elements is that from two different programming languages (Oxygene and RemObjects C# (Hydrogene)) you can target vastly distinct platforms. One side effect of this is that libraries that are created with Elements may be consumed by many different programming languages. Each of these programming languages has slightly different coding conventions, so how can you maintain the conventions on each platform from a single source tree? Here, I’ll lay out some tips to help do just that.

NOTE: I program for neither OS X or iOS. I also don’t have access to a Mac. So, the advice here is for the .Net and Java platforms. However, I would imagine that with minor changes, it would also work on the Cocoa platform.

Which Conventions Matter?

This article focuses on creating libraries that will be used, natively, from other programming languages. Because of this, the only conventions that matter here are ones that affect the symbols that are exported from a library. We will be looking at: property naming, method naming, and namespace naming.

Elements Coding Conventions

For this article, these naming conventions will be used:

upper camel case: PrintUsage
lower camel case: printUsage

Oxygene Conventions

In Oxygene, a source-case-insensitive language, all properties are upper camel case. The same naming convention is used for methods.

RemObjects C# (Hydrogene)

RemObjects C# is a dialect of C# and as such, it follows the standard Microsoft C# coding conventions. This means that properties and methods are both upper camel case.

Targeting Java

In Java, methods have lower camel case naming. Properties, by convention, are a pair of get/set methods that start with either get or set and are followed by the property name. The entire resulting method name is in lower camel case.

Properties

If the naming conventions above for Oxygene and RemObjects C# are followed, properties are taken care of automatically by the compiler. The Elements compiler will turn the following Oxygene:

property Name: String public read private write;
property Address: String;

or the same in RemObjects C#:

public Name { get; private set; }
public Address { get; set; }

into:

String getName();
void setAddress(String address);
String getAddress();

when it creates a Java library.

Methods

Methods are a bit more work. One solution is to use conditional compiling, but that will add a lot of boilerplate typing. Another solution is to use Cirrus. With Cirrus, we can modify methods and classes during compilation.

I have created a Cirrus library in my SugarExtensions project that provides a couple of method aspects. Here is an example of providing a Java name to a public Oxygene method.

[Aspect: Naming.JavaName('printUsage')]
method PrintUsage;

Notice the capitalization of PrintUsage. When a Java library is created, this method will be exported as void printUsage().

When adding a Cirrus reference to the Naming library, you must also add a reference to the Sugar library. Failure to do so will result in compiler errors.

Conclusion

By doing the simple steps outlined here, it is not only possible, but rather easy, to create Java libraries with standard naming conventions from both Oxygene and RemObjects C#. I imagine that it would be just as easy to do this with Cocoa, however, I lack the resources to test this. I welcome pull requests to the SugarExtensions library if someone has time to add and test Cocoa naming aspects.

Blog