Having just shipped 8.3.93, a small update to our major 8.3 release from earlier this year, it's time to take a look ahead at what's coming for Elements, for the remainder of the year and beyond. We have great things planned!
I cant wait. Should be the the Framework support in Fire 8.4 be working ? Last time I checked I couldnât link.
Not in the first beta drop this friday. i hope weâll get the final pieces hooked up for the next beta after, at least for Fire.
Interesting and exciting times indeed. I know what Iâd like Island to be. I think I know what Island probably is. And knowing how reliable both my Wishful Thinker and Crystal Balls are it is probably going to be something else entirely. 
Just one thing on that âUnified Class Syntaxâ moniker ⌠that already caused me a bit of a head scratch since it implies that it related only to classes but aiui it also applies to extension methods and, I presume, global functions. I wonder if âInline (or Unified) Implementation Syntaxâ wouldnât be more descriptive ? 
The first time I read about âUnified Class Syntaxâ my initial thought that it was something to do with simplifying class declarations when dealing with cross-platform variations.
Fwiw you can always suggest things youâd like to see. Canât promise we will do all feature requests but we certainly will look at everything.
i guess. really, i think of âclassesâ as umbrella term for âtypes that matterâ ;). But yeah, itâll apply to interfaces (yes, interfaces), records, extension types, and to methods without a surrounding type such as globals and extension methods), as well. âUnified Class Syntaxâ is really just an internal/unofficial name to throw around, iâm not sure if it needs a âofficialâ name, as once its shipped,. its just âOxygene syntaxâ 
Seconded!
let me know, when the time comes, what each of these were (what you wanted, what you thought it was gonna be, and what it is
No time like the present.
What Iâd like it to be: Win32/64 native codegen.
What I think it is: Linux support
Which leaves plenty of other possibilities for me to be entirely wrong on both counts.
In terms of suggestions⌠one thing that Iâve been pondering on is how the necessary conditional directives involved in mapping types could be reduced/simplified/made more âPascallyâ. I havenât thought it through thoroughly, so the initial ideas Iâve had may be fundamentally flawed, but I was thinking about limited, contextual support for a way of tidying up all those {$if XXX} ⌠{$endif}'s:
Example (from a class Iâve been playing with):
type
Dictionary<K, V> = public class mapped to {$if ECHOES} System.Collections.Generic.Dictionary<K, V>
{$elseif COCOA} Foundation.NSMutableDictionary
{$elseif COOPER} Hashtable<K, V>
{$endif}
public
method Add(aKey: K) Value(aValue: V); {$if COCOA} mapped to setObject(aValue) forKey(aKey); {$elseif COOPER} mapped to put(aKey, aValue); {$endif}
method Clear; {$if ECHOES} mapped to Clear;
{$elseif COCOA} mapped to removeAllObjects;
{$elseif COOPER} mapped to clear;
{$endif}
method ContainsKey(aKey: K): Boolean; {$if ECHOES} mapped to ContainsKey(aKey);
{$elseif COOPER} mapped to containsKey(aKey);
{$endif}
method ContainsKey(aKey: K) ReturningValue(out aValue: V): Boolean; {$if ECHOES} mapped to TryGetValue(aKey, out aValue);
{$endif}
One approach that occured to me was to combine the conditional symbol involved with the mapped keyword, so that where-ever mapped were legal, then $XXX.mapped could be used:
{$ifdef ECHOES} mapped .... [;] {$endif}
becomes:
$ECHOES.mapped ... [;]
You could call it a âconditional mappingâ.
The [;] simply indicates that in the class mapping there is no ; but there would be for a method mapping. I think the compiler should still naturally be able to identify the âendâ of the conditional map clause. To simplify matters such conditional maps must be completely self contained, couldnât be nested and implicitly terminates any immediately previous conditional map.
As far as I can tell, it should even be possible to mix Conditional Maps and conditional compilation without any problems. i.e. both of these should be possible I think without causing any problems for the compiler:
{$if COOPER} $PUREJAVA.mapped to ... ; $ANDROID.mapped to ...; {$endif}
or exactly equivalent but even more concise:
$COOPER.mapped to {$if PUREJAVA} ... {$else} ... {$endif} ;
This is a bit artificial though since neither is really much more âefficientâ than simply using $PUREJAVA and $ANDROID conditional maps (the $COOPER being implicit in those conditional maps).
At the same time, when mapping methods, if the method being mapped to has the same name and signature as the method begin mapped then it would be nice to be able to simply declare it as mapped without having to replicate the signature (this would of course be a compilation error if no corresponding method with the required signature exists in the mapped type).
Applying all that to the class fragment above:
type
Dictionary<K, V> = public class $ECHOES.mapped to System.Collections.Generic.Dictionary<K, V>
$COCOA.mapped to Foundation.NSMutableDictionary
$COOPER.mapped to Hashtable<K, V>
public
method Add(aKey: K) Value(aValue: V); $COCOA.mapped to setObject(aValue) forKey(aKey);
$COOPER.mapped to put(aKey, aValue);
method Clear; $ECHOES.mapped; // method exists verbatim in the mapped type
$COCOA.mapped to removeAllObjects;
$COOPER.mapped to clear;
method ContainsKey(aKey: K): Boolean; $ECHOES.mapped; // exists verbatim in mapped type
$COOPER.mapped to containsKey(aKey);
method ContainsKey(aKey: K) ReturningValue(out aValue: V): Boolean; $ECHOES.mapped to TryGetValue(aKey, out aValue);
To go along with this, I wonder if it might not also then be possible to support a âConditional Method Implementationâ, re-purposing an attribute-like syntax on a method body in the implementation section:
[$SYMBOLA, SYMBOLB]
Which would be exactly equivalent to surrounding the immediately following method implementation (and only that immediately following method) with $ifdef SYMBOLA or SYMBOLB ⌠$endif.
So taking that final ContainsKey method (which is only mapped for ECHOES and requires an implementation for COCOA and COOPER. Currently this looks something like this:
{$if COCOA or COOPER}
method Dictionary<K, V>.ContainsKey(aKey: K) ReturningValue(out aValue: V): Boolean;
begin
{$if COCOA}
aValue := mapped.objectForKey(aKey);
result := aValue <> nil;
{$else}
aValue := mapped.get(aKey);
result := aValue <> nil;
{$endif}
end;
{$endif}
Which might then become something like:
[$COCOA,COOPER]
method Dictionary<K, V>.ContainsKey(aKey: K) ReturningValue(out aValue: V): Boolean;
begin
{$if COCOA}
aValue := mapped.objectForKey(aKey);
result := aValue <> nil;
{$else}
aValue := mapped.get(aKey);
result := aValue <> nil;
{$endif}
end;
This is less about removing/reducing the amount of conditional directive (which in this case donât add much in the way of âcodeâ) but more about simplifying the implementation section where nested $ifdefs and keeping track of which methods are in which conditional blocks can get a bit out of hand when you have larger methods causing those conditional sections to span multiple pages/screens.
Being able to âattributeâ each method individually as required would help keep that simple/manageable.
As I say, none of this has been thought through to the nâth degree and may be fundamentally flawed.
But you did ask.
Funny. Youâll see just how funny, on Friday
Iâll reply to to the rest tomorrow. We have been thinking how to improve this, as part of Gotham, and i think youâre adding some good ideas. Iâll have to read and process them more fully tomorrow.
Full Type Extension support for C#
Support for Constrained Type Extensions
Default Interface/Protocol Methods
8.4 sounds really cool if all these features are available for C#. Itâs far better than MS C#!
For new platforms, is there any plan to support compiling to Javascript in the future?
All three of those will be in C#, yes.
We have currently no concrete plans for JavaScript, Iâm afraid.
Bummer, I was kind of hoping for that. My bosses are trying to rewrite our Silverlight app (boy Iâm going to miss SL) into Asp.net. Our app was ORIGINALLY asp.net and we switched pieces/parts and finally all of it to Silverlight because it performed better and was like a real app and didnât have to worry about state, etc.
So I was hoping you would be able to compile to javascript so I didnât have to get involved in that mess.
Oh well.
I intend to use swift language and I would like to understand 3 things:
Like Gotham and Island are related with the others three platforms (.Net, Java, Cocoa).
What is the difference between Gotham and Island (including in code).
Suppose I want release a class library at all 3 platforms: How the select platform impact my code.
Thanks
Island is a new platform. it lets you compile Swift (and Oxygene, C# and Java Lanuage) code to native Windows and Linux (and potentially more targets in the future.
Gotham is a meta platform: it will allow compiling libraries (mostly) than can then be used on on all 4 ârealâ platforms.
For 3, right now youâll want to build separate projects w/ a Shared Projects; later on you can use Gotham for that.
Dear amazing people,
Iâm darn impressed with Fire, congrats on 9.2 going out into the wild! Iâm amazed at how magically delicious RemObjects is able to leverage Oxygene, C#, Swift, and Java to target .NET/Mono, JVM, Cocoa, Win32/64, and Linux. That is nothing short of⌠mind-blowingly wow!
So Iâm curious as to what the roadmap is for the future.
Thereâs the obvious âincorporating the evolution of C#, Swift, and Javaâ, since those languages are undergoing paced change by their respective stewards. And RemObjects is the steward of Oxygene, and I presume it is also being nurtured and evolving and moving forward too.
Are there new platforms that Elements will target? Web apps? Node.js? Raspberry Pi?
Are there new languages that Elements will leverage?
I suppose popular languages are always being scrutinized to see if theyâd be a good fit for Elements. Such as C++17 or Microsoftâs one-off C++/CX. TIOBE lists out the month-by-month language popularity.
My own druthers would be Elements to support D (from Walter Bright & Andrei Alexandrescu) and F# (from Microsoft & Don Syme). In my own order of preference, although I imagine F# would be easier to implement since it is already a first-class citizen language on the .NET platform.
The biggest lacking for D is a good IDE to support it, and that a single-letter language is difficult to search for on the internet. (Maybe RemObjects would call their implementation Nitrogene, thatâd be searchable!) Since D is a systems language instead of an applications language, perhaps that would make it a less suitable fit for Elements.
Now that Google has endorsed Kotlin, I can imagine that it is also under consideration. Even though it originated from those other IDE folks⌠theyâre good people too.
And there are other on-the-map languages like Scala, Groovy, Clojure, Elm, Haskell, OCaml, and the list goes on and on and on.
Well I realize that asking for a road map would be showing your cards and that is asking a lot. I suppose you canât show those cards until things come together and are nearly ready to ship. Be that as it may, I understand. Iâd be happy with whatever you can share.
Sincerely,
Eljay
John,
thank you very much for the kind words. very much appreciated!
Raspberry Pi is actually covered already, with we have ARM support for Island/Linux, since (i believe) 9.1 and that specifically includes rPI. Weâre definitely looking at webasm as one of the next targets for Island â i canât promise timeliness, but itâs something weâre exploring, and seeing a lot of interest for.
Yeah, weâre keeping up with the first three (C# 7 and 8 features are in the works, most fo Swift 4 is covered), and w have some cool stuff for Oxygene planned as well for the next year, though nothing to announce yet (we did recently add the new Unified Class syntax, which personally think is the best thing to come to Oxygene since 1.0
We are always looking at/considering new languages, but weâre hesitant to add too many ;). Adding a new language, as we just did Java, is a lot of work aside form the core compiler support, and essentially adds new âdimensionsâ to everuytbign we do (every template, every sample, etc needs to be tested/supported in all languages, etc).
Kotlin is definitely the language that weâre mist closely watching right now â though TBH itâs so similar too Swift that i;m not sure if i see a good case for us having to support both âdialectsâ, aside from fulfilling the checkmark. Kotlinâs main goal seems ot be to be a âSwift for Android devsâ, and we have that already covered one better having actual Swift for Android devs
Dartlang can be an option.
Then i can use same class for javascripts too
Personally I think the four current languages are sufficient. Iâm excited to see what is coming next to make cross platform development easier and to finally find out wth Gotham is!?!
Thereâs no dearth of languages out there that, for each, a handful off people are excited about, yeah
We donât need another hero âŚ