Reflect.hx

[Simn]

• [x] hasField (only supported on anons as specified)
• [x] field
• [x] setField
• [x] getProperty (can't remember if this has can just go by convention or actually has to check something)
• [x] setProperty (same)
• [x] callMethod (there's an implementation but probably 20000 corner cases)
• [x] fields (only supported on anons as specified)
• [x] isFunction (should come down to an instanceof check against MethodHandle)
• [x] compare (partial implementation, have to make it robust)
• [x] compareMethods (have to check the field closure case)
• [x] isObject (this one is annoying... see below)
• [x] isEnumValue (I have this already in Type.hx, just have to move/call it)
• [x] deleteField (should only have to call _hx_deleteField on the object)
• [x] copy (uhm... cast to java.lang.Object and clone?)
• [x] makeVarArgs (headache)

Regarding isObject: The problem with this is that we always box primitive values when assigning to Dynamic, as is the case here. This means that isObject(12) and isObject((12 : Null<Int>)) are indistinguishable within the function body.

The genjava implementation solves this by doing a whole bunch of Std.is checks against java.lang.Number, java.lang.Boolean etc. The question here is if we're talking about "object" in the run-time sense or the Haxe-sense.

[Simn]

deleteField requires hijacking any field write operation on the object. That's the only way we can re-install a previously deleted field. What a pain...

[Simn]

All done!