Writing something on using Metatags

[Shaun Michael K. Stone]

I am writing a book on Haxe in Action, and would like to check my accuracy of the example below and how it could perhaps be improved?

 Let us take a look at an example taken from the OpenFl library.

    package openfl.display;
 
    #if !flash #if !openfl_legacy

    @:access(lime.graphics.Image)
    @:access(lime.graphics.ImageBuffer)
    @:access(lime.math.Rectangle)
    @:access(openfl.display.DisplayObject)
    @:access(openfl.display.Graphics)
    @:access(openfl.geom.ColorTransform)
    @:access(openfl.geom.Matrix)
    @:access(openfl.geom.Point)
    @:access(openfl.geom.Rectangle)
    
    @:autoBuild(openfl.Assets.embedBitmap())
    
    class BitmapData implements IBitmapDrawable {
    ...

The metadata tag -- known as **@:access** is telling the compiler, "Hey, for this class we want to force private access to these packages of our library." So in this instance, BitmapData is forcing access to private types and fields that would otherwise not be accessible.

Is this a good explanation?

Thanks,

Shaun.

[Mark Knol]

I like the "Hey" to start the description. I think in general sense you are correct, did you see the manual on this topic? http://haxe.org/manual/lf-access-control.html

[Shaun Michael K. Stone]

Yes I did read that. Explains access control well. My question is why would you actually do this? Surely if something is meant to be private, then it shouldn't be accessible? Why are we 'hacking' the compiler to do this? Also what are good examples of using the other meta tags? I can see their descriptions on the meta list, but I can't personally think of ways to make use of them. Like the noCompletion tag, I see this is also used a lot in the OpenFL library. What is it doing?

Thank you.

[JLM]

The concept of private in Haxe is purely to help the Haxe developer, if the Haxe developer decides they need access to something private then they can either through casting to a typedef with that access public or via access as you describe, or via reflection and access the private property or function.  The concept is that private is an indication that something is encapsulated and not designed for a code user to mess outside the class, but the original developer of that class can not predict every use case. So Haxe takes the firm view that if the developer decides he needs access anyway, but does not want to change the class, inherit or jump through a million hoops he can.  Haxe provides tools to enable and empower, Haxe as a language puts power in the developers hands and believes in developer responsibility.  Similarly you can use Dynamic everywhere in haxe if you really want to but that would be very foolish, but that is your developer responsibility.  This is partially why Haxe does not have protected as well as private because the difference in some languages is purely to control how a developer uses a library, but Haxe believes that is ultimately the developers choice since to fork a library just to access one parameter is kind of mad but the sort of thing I end up doing from time to time when I have to code in as3.  Any book covering Haxe should explain that Haxe follows best practices but still remains highly pragmatic, the best example of this is Dynamic which Nicolas once described as Dynamite because the effects of one Dynamic can easily propogate and ruin the power of the compiler to spot your mistakes, Dynamic is in Haxe for purely pragamic purposes, and I cringe when I see it used when it really could be avoided.  Maybe if you study Openfl you can suggest an alternative to the many @access approach to the author as it does seem a lot, but it's developer responsibility. Haxe tries to avoid disabling the developer while still helping them.

[Domagoj Štrekelj]

Haxe provides its own completion server for other IDEs to use. It is my understanding that the @:noCompletion compiler metadata basically prevents the completion server from providing code completion (or code hints) for the associated field. In a sense, this also adds another layer of privacy to the codebase by controlling what a user views as "accessible" to him. These "hidden" fields can be used without error, of course. It's just that nothing aside from the source code would point to their existence. An example use case of the @:noCompletion metadata is to hide getter and setter methods, reducing both code hint clutter and chances of the fields being accessed.

A lot of the metadata listed in the Manual is self-explanatory. Those that seem mysterious should be observed with some context. A simple search of GitHub repositories will provide lots of examples.

[Shaun Michael K. Stone]

Thanks for that, very helpful!

[Shaun Michael K. Stone]

Thank you for the understanding.