This is just a little update on what I've been getting into over the last 2 weeks (ie ...since I became more scarce here)
Well, first off, I am absolutely still working on my game engine and a game but, I had to take a little break to upgrade my skills in another language. Using AIR (AS3) for mobile is fine (IMO) due to the fact that everything gets wrapped up nicely in an APK. Using AIR for native platforms however is messy. This is mostly due to an entire AIR runtime being coupled to the executable in a portable manner. In short, if I need to include some .dll's with my .exe no biggie...including an entire AIR captive runtime is ridiculous. Not to mention that the entire reason the runtime is included is because the .exe is just some wrapper bullshit and the app is still running in a VM.
All that being said, I decided to really learn HaXe. I had a working knowledge of HaXe by using the method where I practically just rename my AS3 classes and do some simple project-wide find/replace-all operations but, that's not ideal. It's much better to actually know where various native targets are supported and be able to write code that accommodates accordingly:
if windows DO IT THIS WAY
else if linux DO IT THIS OTHER WAY
else if IOS USE THIS OTHER METHOD
else THIS SHIT AINT GONNA WORK FOR YOU
HaXe is pretty good at supporting all targets for most things but, not everything. By getting a deeper understanding of what is really going on and paying attention to support lists for various packages I can program with more confidence and with greater ease. I have an idea for a simple app that contains a couple of advanced features. I'm only building it as a way to become comfortable enough with HaXe to start porting my engine without stumbling over a bunch of small and stupid things that don't need to happen if I just get a better education first.
As far as my current level regarding HaXe programming is concerned I would like to say that I am a strong intermediate. I've gotten to the point where I am even properly guessing possible packages to use before I even check to see if they exist. One example is sys.FileSystem. I was using sys.io.File to save a file but, then I decided to check if the file existed before saving. At first I used sys.io.FileSystem.exists(path) and it gave me some half baked error. I remembered that in some other language I know (I forget which one) the FileSystem class was ?above? the File class so, I tried sys.FileSystem.exists(path) and voila...success. Every bit of that was guessed. I could have just as easily got error after error until I decided to check and find out there is no FileSystem class or they put it somewhere else or it doesn't have an exists method, or exists expects more than one argument...on and on. None of that happened, though and this is only one example of me guessing my way through the language with success.
Another reason I feel right in saying I'm at a strong intermediate is my almost complete lack of syntax and type errors. In AS3 Objects can be Null and they can be anything. For instance I can make an Object an actual Object similar to JSON or a Struct, or an Object could be nothing but a string or int or anything else you can think of. Basically, Object is equivalent to Dynamic. In HaXe there is no such thing as an Object, there is a Dynamic but, you really shouldn't use Dynamic unless you have no choice. To make things more complicated, I remembered reading somewhere that most things in HaXe can't be Null (like string, int, bool, etc). I was writing some typedefs to mask OpenFL classes which duplicate AS3 components in order to design them externally with JSON files, and use the typedefs to basically type check the imported JSON, by simply treating the JSON as a struct that was typed to the typedef. I hit one small wall. OpenFL strictly follows the flash signatures which include strings,booleans and ints that are typed as object in order to utilize it's nullability. I could have just sucked it up, tried not at all and typed it all as dynamic but, I decided to try something: Null<Bool>, Null<String> etc... It totally worked and I maintain type checking at compile time where I would have immediately lost that with Dynamic.
I'm pretty sure these types of examples push me clean out of the novice league into at least the intermediate. I could give more wordy and complicated examples of me practically just already knowing this language but, instead of that I'll just say that's where the "strong" comes from in my "strong intermediate". I believe in 2 more weeks I'll be scoped beyond what I need to be in order to rebuild my engine in HaXe.
For the record, It's not all a bunch of successful guessing. I have done PLENTY of studying. Using HaXe solo is definitely useful but the real power comes in extensions like NME, OpenFl, Lime, plenty plenty more. Learning HaXe is barely about learning a language at all (well when you know as many languages as i do anyway). It is far more about learning a bunch of API's and making sure that all your API's are supported by the same version of HaXe and in some cases versions of the other APIs. A good amount of time could be spent on just making sure that your project has balanced APIs. I switched my OpenFL version from 3.5.3 to 3.6.1 and it broke everything. I upgraded my HaXe from version 3.1.3 to 3.2.1 and it fixed some things and left other things still broken. I eventually scrapped the broken API's and found replacements. Where I wasn't able to find a replacement (just one API) I just wrote the features I needed from scratch against the current HaXe library. It's not all perfect guesses and wins. There is definitely a very broad range of things to consider and learn. However, the results allow me to spit out masters for my code in languages that I don't even know (c++, java, lots and lots more) and so far it all works very well.