Haxe 4.0 final field enforcement gap on dynamic targets

Short answer

No. Haxe 4.0's final modifier is a compile-time check only. The compiler does not inject runtime immutability guards for dynamic backends such as JavaScript or PHP, and there is no standard configuration option that blocks Reflect.setField or equivalent reflection APIs for fields marked final.

Confirmed behavior versus open questions

Assuming Haxe 4.0.x, the following behavior is well established:

• The type checker rejects reassignment of a final field inside Haxe source code.
• On JavaScript and PHP targets, final is erased during code generation; the emitted property remains writable.
• Reflection APIs such as Reflect.setField can mutate a final field at runtime on dynamic targets.
• No Haxe compiler flag is known to enable runtime guards or reflection blocking for final fields.

Whether a future Haxe release will add runtime enforcement is unsettled. Treat runtime immutability as absent unless you verify it against a specific compiler version and target.

Verification

Compile this minimal class to JavaScript:

class Foo {
  public final bar: String;
  public function new() {
    bar = "initial";
  }
}

Then run in the generated JavaScript context:

var foo = new Foo();
Reflect.setField(foo, "bar", "mutated");
trace(foo.bar); // prints "mutated" on JavaScript

If the value changes, the field is not runtime-immutable. Inspect the generated JavaScript to confirm there is no const, getter-only property, or frozen object.

Recommended mitigation

Because the compiler does not enforce final at runtime on dynamic targets, enforce it in the emitted code or limit access to the instance:

1. For JavaScript, wrap the instance in Object.freeze after construction if the object shape is stable.
2. For PHP, use native read-only typed properties or another runtime wrapper; Haxe's final does not automatically map to PHP read-only properties.
3. Do not rely on final as a security boundary in browser or server-side JavaScript; any script with access to the instance can mutate it.

Missing diagnostic detail: which dynamic target are you shipping, JavaScript or PHP? The appropriate fallback differs by runtime, and knowing the target determines whether Object.freeze or a native read-only property is the right mitigation.