I’ve read couple threads / haxe manual and know it not exist. But I still have couple questions for “private” simulate workaround.
OpenFL uses “__” prefix for inner fields which shouldn’t be touch on develop. Also HaxeDevelop hides list of this “__” fields from autocompletion and that fields seem not marked as “@:noCompletion”. So how they made that hiding possible?
On the other hand I might develop core classes and run “find and replace” for like ‘private var _’ -> ‘@:noCompletion private var _’. Is there any better workaround (not learned haxe macroses yet)?
What if subclasses should have same named real “private” fields like method “_init”. How you, guys, solve that issue? Naming “_initMyClass” looks pretty silly… Also for class name refactoring I should manualy rename that “_init” function at each class for proper readability. Is there any metatag I’ve missed which may provide autorename functionality? Like rename subclass method “_init” to “_initSomeRandomValue” during compile time.
OpenFL uses double underscore values in order to prevent the name collision you are mentioning. It came up as a convention for being private to the OpenFL library, without colliding with most user code. OpenFL uses Haxe, which has public and protected style variables, but not private like other languages. Some of our target languages might not actually support true private variables, so preventing name collisions is real. One exception is __init__ which is run automatically per class, which might help with some of your issue, though be careful – it occurs before some other class types might not be initialized yet, so it’s for certain kinds of initialization only.
OpenFL actually has a set of extern classes that mirror the API. This is how it hides the private members without @:noCompletion, and how it hides internal classes as well. Otherwise that’s the way to do it.
An auto-rename would be an interesting feature, the trick would be how to rename all references
I meant Haxe team could make real “private” access at compile time only. Of course, result might contain all public fields. But it will be enough for comfortable writing core libraries on Haxe.
auto-rename is a small feature which shouldn’t be too hard at my opinion. Like @:privateField. So compiler create random add to field name and checks all calls to it inside Class code and renaming it too. super._field should be restricted with private metatag and throw error right while code writing. Subclasses wont see metagged field as it behavior will also include "@:noCompletion" tag.
I see at project setting this “extern” path. But if I press “F4” on Class name HaxeDevelop shows me OpenFL source code (no any “extern” constructs or something). Is it some kind Lime/OpenFL magic?
That’s probably due to HaxeDevelop’s custom parsing / classpath exploration. In VSCode, which uses the Haxe compiler for everything, it should only show you the externs.
