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.
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()
.
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.
Leave a Reply