Why does `@:privateAccess` exist?

I’m still new to Haxe, so maybe this is normal/idiomatic, but I still have to ask: why does Haxe have @:privateAccess and other metadata like it?

It seems to break the purpose of the private keyword. Even the docs don’t seem to explicitly mention its intended purpose:

If a library author makes a field private, it seems like anyone who imports that library can use @:privateAccess to access it? Despite the original author’s intent on how their API worked? Or am I misunderstanding?

I ask because I noticed that going from Haxe 4.0.5 to 4.1.1 seemed to break HaxeFlixel despite it being a minor version bump, because OpenFL was using @:privateAccess to access a private property:

/usr/local/lib/haxe/lib/openfl/8,9,6/src/openfl/display/Stage.hx:1426: characters 46-59 : haxe.CallStack has no field lastException

Relevant conversation in the Discord: https://discordapp.com/channels/162395145352904705/165234904815239168/716184557434699806

I can see the usefulness in accessing private fields, but it seems like it’s more likely to break APIs and prevent semantic versioning from working as intended.

Haxe provides ways to sidestep language restrictions when “you are sure what you are doing”. Like Dynamic and other “hack-it” metadata, generally you shouldn’t be using them. But when you need to, you can use them, at your own risk.

Haxe generally follows the philosophy of “you know what you’re doing”. @:privateAccess and friends are actually even pretty harmless compared to what you can do with macros, you can use those to rewrite code in third-party libraries at compile time if you want.

1 Like

In languages without such meta you’d likely use reflection to try and get access, which is even more likely to break.
But yeah like the others have mentioned, you need to know what you’re doing when doing that.

1 Like