This is a quick follow up post to further tease some of the exciting developments in the world of RemObjects Elements. Yesterday I posted about implementing a Windows version of my trivially simple RandomNumber application. Today, I present another Windows version.
But this one doesn’t use .NET.
First of all, the end result:
True, it’s not as pretty as the OS X, Android or .NET versions of the application because as of right now the CPU-native codegen for x86/x64 only supports console applications (the same holds true on the Linux side of things. Currently).
So let’s take a look at the code involved:
namespace RandomNumber.Win32; uses RandomNumber; type Program = class public class method Main(args: array of String): Int32; begin writeLn('The magic happens here.'); writeLn((new RandomNumber).next(100).ToString); end; end; end.
Unified Class Declaration
The first thing to notice is that this looks a little strange for a Pascal implementation.
The template for an Island Windows Console Application produces a source file using the new Inline Implementation Syntax (a.k.a Unified Class Declaration) support in the latest Oxygene compiler (beta).
That is: There are no separate interface and implementation sections. The implementation of methods can be provided inline as part of a class declaration itself.
Scratch one more reason for the curly bracket brigade to dismiss Pascal. 🙂
For larger, more complex classes I personally think that the separation of declaration and implementation makes for more maintainable code, and you still have the option of using that syntax in those cases (or as you see fit). But for small, lightweight classes such as this entry point class or extension methods etc, this inline syntax has a lot going for it in eliminating/reducing duplication of method declarations.
This syntax flexibility is available across all Oxygene platforms, obviously, and is not limited to only Island projects.
Cross Platform Concerns
The next thing to notice is that this implementation again makes use of my RandomNumber class. I have extended the implementation of that class to cater for the native codegen platform. With no .NET Framework available to a CPU-native application this means having to take a similar approach as adopted with the COCOA implementation for RandomNumber. I could have implemented my own PRNG from first principles (and the lack of Posix style PRNG state buffers in Windows means that if I were intent on a comprehensive, cross-platform PRNG implementation then I might have to consider that). But for the purposes of a quick proof of concept, I instead tried to use the C RTL functions provided by Elements’ own rtl namespace.
I say “tried” because I ran into a bit of a problem here however in that trying to use the rand and srand functions of the rtl resulted in a linker failure. The timeGetTime function presented no such problem however.
It’s perhaps to be expected that there will be some teething troubles like this in what is after all the very first beta drop of this technology.
Something else to mention here is that importing functions from DLL’s is supported in Island projects, so I could have imported these functions from the Windows C RTL DLL myself. But for now, a Not-at-all-PRNG was good enough for this exercise. I could have simply rolled a dice; any solution here would be a temporary kludge but I settled on returning the current timer value mod‘ed to the specified limiting range:
method RandomNumber.Next(limit: Integer): Integer; begin // Temporary bodge: result := (rtl.timeGetTime mod limit) + 1; end;
Other aspects of the RTL are clearly working perfectly, such as the availability of a ToString() method on the Integer type return value of my next() method.
The final thing to note w.r.t cross platform questions and this code is that there is nothing in this program source file that is platform dependent. You could place this program.pas file in a shared code project and then re-use this program source directly in Java, .NET and OS X console applications, as well as this Win32 application.
You might be thinking that without .NET to hold my hand I appear to have recklessly leaked a RandomNumber instance. But if we take a look at the default references setup for my project in the solution we can see a clue as to why this is not a problem:
Yes. Island projects are CPU-native codegen but they also benefit from having a Garbage Collector. For those interested in such details, I understand it is an implementation of Boehm GC
I mentioned yesterday that Island also supports Linux CPU-native codegen. I personally don’t play in the Linux space and do not have a Linux VM to hand with which to repeat the exercise for Linux, but I have no difficulty believing that it would be just as straightforward.
Beta Access and Availability
If you are interested in these developments, you might be wondering how you can get involved in these beta’s ?
RemObjects makes beta versions available to all current subscribers to their compilers, so if you are interested in exploring the capabilities of these new platforms (and of course the existing .NET, Java/Android, iOS and OS X platform support) you only need to be a customer.