I am considering writing an api using RTL. As I understand it, RTL itself is made in Oxygene. Does it make sense therefore to pick Oxygene as the language to use?
As all languages within the elements family are (almost) equal, I think it make sense to use the language that you are most fluent in; Oxygene or one of the other languages.
1 Like
I read that RTL in some cases uses it’s own implementation when no suitable exists in the platform - which uses Oxygene
I am kind of forethoughtful about potential upcoming of RTL packages at some point (would that come to be?). I would also like to learn Oxygene in case I would contribute to RTL:)
On the other hand I would be much more productive short term using C# for instance
In general, i would echo Theo’s suggestion: use the language you prefer; most anything you want to do can be accomplished in any of the languages, and still be consumed from any of the languages.
If the latter is a concern (like you want your API usable from all Elements languages), you do want to be on the lookout for a couple of areas. for example, some very Swifty-designed APIs (especially named first parameters, e.g. save(string:, toFile:) or the like) can be awkward to be called from other languages.
One thing i want to mention though: if you think any of the APIs you are planning to create might end up being great additions/contributions to Elements RTL itself, then it would be a bonus if they are done in Oxygene, as we prefer to not mix languages too much within single projects such as this, unless necessary.
In that case i’d say start with C#, learn Oxygene on the side (maybe by using it for some smaller parts — remember, you can mix and match in the same project, so you could literally just do a single class in Oxygene, to try it out or to use a fancy Oxygene feature).
2 Likes
Is there a long term thought of having RTL packages? What I mean by this is for instance to have a permissions package: There is Xamarin.Essentials that does this in .Net, (camera permission, location permission), and the same for the other platforms (cocoa, android eg)- so you end up with an RTL permission package?
Ill keep in mind I can mix languages
I’m open to the idea of (a) adding all sorts of additional abstraction APIs to Elements RTL, where sensible and (b) splitting those into separate packages if and when Elements RTL itself would get too big to keep it all in one place.
Permissions definitely are one API that would be good to abstract. I started abstracting location API access for Android and iOS myself privately for a project I’m working on, thats one candidate for moving into Elements RTL, once/if I ever get that streamlined enough. Map access might be another (more tricky) one that I’m also looking at for my personal project.
These would definitely need a split, as Elements RTL for Java, at least, currently doesn’t require/use any Android APIs — once we exchange that, we’d either need two separate copies for Android vs plain Java, or a split. On the iOS side, this is not an issue.
oh, and I forgot to say: welcome to Elements!
Thanks and very interesting!
I think DateTime in RTL seem to illustrate well how the platform class are added in Oxygene.
Is the type requiring a class? (I can’t somehow throw a whole nuget or cocoapod in there right?)
It would be nice to take look at your location API if I could.
I’m not sure what you’re asking here ;).
I’ll see what I can do next week. it’s pretty rough/early days and deeply embedded in the actual project right now.
package
{$IF COOPER}
MyRTLPackage = jar;
{$ELSEIF TOFFEE}
MyRTLPackage= cocoapod;
{$ELSEIF ECHOES}
MyRTLPackage = nuget;
{$ENDIF}
end;
I am sort of hoping the same concept could be applied to package level:/
Hmm, not exactly, that doesn’t happen at the language level, references get resolved on project level, pre-compile. But you could of course reference any jar (for Gradle package) for your Cooper project, or NuGet one for Echoes (we don’t support cocoapods).