Testing if v is an Array: v is Array … see Try Haxe!
If you want to know if v is an Array<T> for some given T then generally speaking, that is not possible at runtime, because most targets erase parameters at runtime (like Java, that you mentioned before). Then again, this is not something you need for serialization, because you’ll have to introspect every item individually anyway.
Runtime type information doesn’t come for free. Since HashLink is primarily meant for game development, where performance matters and data structures are often tweaked for compactness to achieve better cache locality, I wouldn’t hold my breath for this to happen.
Also Haxe not being strongly coupled to a fat runtime like most managed languages are, is a unique quality of Haxe that is a strength, not a weakness.
Again, HashLink is designed around various performance considerations, like decreasing the overhead of data types that are quite unique to Haxe (e.g. anonymous objects and enums). RTTI is at best orthogonal to that goal, and may even be at conflict with it at times. It’s not a primary concern and it’s not really a good default.
You will also find that Haxe has many compile time features (such as abstract data types) that disappear entirely at runtime. Dragging around all of this is just not practical.
Instead, you should clearly define a problem, determine how much information you can get at compilete time (always preferable) and then see what’s left to close the gap at runtime and you may then have to figure out a platform specific way to get that information, or see how far you can get with the cross platform reflection capabilities:
Perhaps the problem lies herein. Yes, you’ve picked an intersting problem, but it’s not really all that natural. Haxe is a pragmatic language, aimed to solve real world problems, primarily those of a small game studio in Bordeaux, although other community members are using it for other purposes. Building a reflection based serializer is not a real world problem, especially in a language that has one in the standard library: haxe/std/haxe/Serializer.hx at development · HaxeFoundation/haxe · GitHub
The std serializer has been there since Haxe 1 IIRC, when Haxe was a far less capabable language than it is today. It is comparatively slow and relies on reflection, which on many targets makes the generators output extra RTTI, which - as established above - doesn’t come for free.
These days you will more commonly find serializer libraries that are built via macros at compile time, using compile time type inspection, which has full information and can provide meaningful errors (e.g. if you’re trying to serialize a function, the macro can tell you that that’s not going to happen - that or if the serialization is tied to some stateful connection, it could serialize some ID where the deserialized function will use said ID to perform some form of RPC call).
There’s a number of examples:
- Binary - hxbit: GitHub - HeapsIO/hxbit: Haxe Binary serialization and network synchronization library
- Binary - tink_serialize: GitHub - haxetink/tink_serialize: Macro based serialization. Fast & compact. Deal with it.
- JSON - json2object GitHub - elnabo/json2object: Type safe Haxe/JSON (de)serializer
- JSON - tink_json: GitHub - haxetink/tink_json: Macro powered JSON.
There’s also a bunch of serialization libraries here, all of which are reflection based as far as I could tell at first glance: Tag: serialization
In conclusion I would put it to you that Haxe’s strength lies in the fact that if you want to have behavior that is derived from the structure of the data, then rather than discovering it at runtime and then branching (in essence building an interpreter), you can inspect it at compile time and generate the appropriate code (in essence building a compiler).
And I would really advise you to start with a real world problem and then build some sort of solution from there. Haxe may not even be the best choice. It definitely isn’t if you don’t properly consider how its more advanced and often quite unique features are best leveraged to tackle said problem. If you just try to use it as a dorky version of Java, you definitely will get nowhere 