rtl namespace represents the fundamental “raw” RTL at the OS level such as Win32 APIs and associated data types, macros, constants and structures.
IslandRTL (represented as RemObjects.Elements.System) is the RTL for Island platform that works on native Windows, MAC, Linux etc. It is the RTL for the Island platform, and one ABSTRACTION level higher than RTL
Element RTL (current version 2, ie RTL 2) is one ABSTRACT level higher than IslandRTL, such that unifies the interfaces on Island, .NET, and Java. It is the RTL for all RemObjects Element Languages
So in terms of “platform abstraction” level, RTL < IslandRTL < RTL2
@mh please correct if any inaccuracies or mistakes
String is sealed, so there’s nothing to override, ever.
All the major “non-native” platforms come with their own rich OOP APIs to be usable. the .NET Framework, The Java SDK, the Cocoa/AppKit/UUKit frameworks. Island is low-level and (aside from macOS/iOS, where it can access Cocoa) there are no existing standard OOP paradigms present (eg Win32 API, or Linux libc). SO Island has Island RTL to provide a common OOP layer of functionality, provide Object, String, etc.
All these platforms are usable as is, with the vendor APIs (and Island RTL), and without any additional libraries…
Elements RTL is an optional extra library that provides an abstraction layer and gives you common functionality with identical AP:Is across all platforms — if you so desire. The same String class API. The same List and Dictionary — whether you work on .NET, Java, Cocoa or Island. This is so you dont have to worry about the NSArray on Cocoa vs System.Collections.Generic.List on .NET, or NSXMLDocument vs XmlDocument, etc. A common set of APIs for base functionality that work on all platforms.
You can use it from Island, yes. And while it is a great general purpose API (I use it for all my projects(, even single-platform ones), it’s main goal is to provide a consistent API for multi-platform projects.
Some native platform specific methods are not available with Elements.RTL, for example, String.FromAnsiChars
Elements.RTL contains some useful extension methods for Island RTL classes, for example, List.JoinedString.
Referencing Elements.RTL first, then IslandRTL, will make my code primarily use IslandRTL classes + extension methods defined in Elements.RTL
Of course, I do this only because I care “intra”-Island native interoperability (like native Windows/MacOS/Linux, thanks to Island’s LLVM backend). I don’t care much about the cross-platform interoperability among Island/.NET/Java/Coocoa. Hence I only use Elements.RTL to augment IslandRTL., while using IslandRTL as primary - which is achieved by the order of referencing Elements.RTL first, then IslandRTL afterwards.
Note that both String “types” are the same at runtime, and you can seamlessly and toll-free cast between them; they merely provide different APIs.
RemObjects.Elements.System.String is the actual string type as implemented in Island RTL. It’s APIs are sp[ecific to Island, but modeled largely after .NET. But it’s API will be incompatible with Cocoa and Java Strings (and less so, but still, with .NET).
RemObjects.Elements.RTL.String is the idealized “cross-platform” API we envision for strings, regardless of platform, and it looks the same omg all platforms. I’d be open to feature request if important APIs are missing or you think should be exposed — as long as these APIs are sensible on all target platforms.
You can always “down-cast” a RemObjects.Elements.RTL.String to the native string, if you need to call an API thats on native but not in Elements RTL. You can also seamlessly assign native strings to RemObjects.Elements.RTL.String, and vice versa or, e.g. for tom use the native .ctor ebvewn when otherwise using Elements RTL, eg>:
string foo; // typed as RemObjects.Elements.RTL.String
foo = new RemObjects.Elements.System.String(<paramters for a ctor not exposed in ElemengtsRTL>);
foo.ToUnicodeCodePoints; // call an Elements RTL API
(foo as RemObjects.Elements.System.String).Whatever // call an Island String API
@mh thank u for the heads up. Good to know the trick.
For users like me who primarily use Island (and love it), it would be more convenient that referencing RemObjects.Elements.System will automatically introduce those extension methods defined in RemObjects.Elements.RTL, rather than explicitly down/up casting back and forth.
But I guess I am happy with the way it is, i.e., referencing both RemObjects.Elements.RTL and RemObjects.Elements.System, with the specific order.
Good idea. The idea behind only showing the mapped methods is that of your coding cross-platform, being both will be confusing, and you easily end up writing platform-specific code again. But for single-platform use, I could envision an option where mapped types extend the original, rather than hide it.
I’ll bring this up with the compiler team for what we can do here — maybe a per-project compile option?
ideally, id make the Element RTLs as well-rounded as we can so you never need to drop down to the native types (except maybe for really corner-case stuff).
Feedback appreciated as to what is missing — I as looking at island RTL’sstirng for may above code example, and couldn’t really find any method it had (except maybe the extra .ctors) that Elements RTL doesn’t already also expose…
So please try putting Elements RTL int the closest scope and let me know what you actually miss when you do!
Hi marc, thank you for your attention. At least, the following code won’t compile, complaining String.FromPAnsiChars and String.ToAnsiChars are missing
Program = class
class method Main(args: array of String): Int32;
// add your own code here
writeLn('The magic happens here.');
var str1: String := 'test';
var str2: String := String.FromPAnsiChars(@str1.ToAnsiChars(true));