Many languages support metadata in the form of additional information attached to classes, methods or variables. In this post I provide a sample implementation to produce such a thing in haXe.
I created a class Attributes (source code attached to this post) with the following signature:

class Attributes {
public static function of(cls : Class, ?field : String) : Attributes;
public var parent(default, null) : Attributes;
public function exists(key : String) : Bool;
public function get(key : String, ?alternative : String) : String;
public function set(key : String, value : String) : Void;
public function isInherited(key : String) : Bool;
public function keys() : Iterator;
public function iterator() : Iterator;
public function toString() : String;
}

Instances of the class cannot be created directly but they must be obtained using the static method Attributes.of(). The first parameter is the type of the class we want to retrieve attributes, the second optional parameter is a field of that class (it works with either static or instance members). The class is very similar to Hash with the exception that attributes are inherited; so class B that extends class A can inherit or redefine the attributes of B.

Let’s see how we can use the class.

import attributes.Attributes;
import haxe.rtti.Infos;

/**
* @author Franco Ponticelli
* @year   2009
*/
class Main implements Infos {
/**
* @role entry point
*/
static function main() {
trace("attributes of Main: " + Attributes.of(Main));
trace("attributes of Main.main: " + Attributes.of(Main, "main"));
}
}

The output is:

Main.hx:15: attributes of Main: { author : Franco Ponticelli, year : 2009 }
Main.hx:16: attributes of Main.main: { role : entry point }

In the first case we have retrieved the attributes of the class Main while in the second the attributes of its method main().

If you want to try you can’t forget about two things: classes that provide attributes must implement haxe.rtti.Infos and you must add the directive -D use_rtti_doc when you compile your project. The latter informs the compiler that nodes must be included in the generated code.

One nice thing about attributes is that they are both “code” and documentation. Attributes can have a lot of applications, in ORM they can be used to wire a class name to a SQL table name or to map fields and relations to columns; in controllers they can be used to bind a method to certain credentials or templates; in a unit testing system they could be used to mark the functions that are test methods.

There is one thing are a couple of things to consider before embracing this technique, rtti info are stored as XML in the code and the parsing can be slow (the provided implementation caches the results to speed things up) and there is currently a bug in the -D use_rtti_doc: overrode methods do not bring their documentation so attributes attached to them are simply discarded. Hopefully the latter problem will be addressed soon. (bug fixed in CVS, version 2.05 will be bug free)

download here: Attributes.v.1.0

If you are experienced with haXe you’ll know that its type system permits to catch a lot of errors at compile time simply veryfing that parameter/member types are correctly used in your application. Members can only have two access modifiers: public or private. But what if you want to emulate something like the “friend” modifier that exists in other languages?

Let’s see a practical example.

class Test {
  static function main() {
    var c = new Container();
    var n1 = c.add(new Item("John"));
    var n2 = c.add(new Item("Jane"));

    trace(c);
    trace(n1);
    trace(n2);
  }
}

class Container {
  public function new() {
    children = new List();
  }
  public function add(n : Item) {
    children.add(n);
    return n;
  }

  public inline function iterator() { return children.iterator(); }
  public inline function count() { return children.length; }

  public function toString() {
    return "[Container] has " + children.length + " children";
  }

  var children : List;
}

class Item {
  public var parent(default, null) : Container;
  public var name(default, null) : String;
  public function new(name : String) {
    this.name = name;
  }
  public function toString() {
    if(parent != null)
      return "[Item] " + name + " has " + (parent.count() - 1) + " sibblings";
    else
      return "[Item] " + name + " has no parent";
  }
}

This flat hierarchy proves my point because something is missing, the Item instances never receive a reference to their container and the field parent is always null. The output trace is:

Test.hx:8: [Container] has 2 children
Test.hx:9: [Item] John has no parent
Test.hx:10: [Item] Jane has no parent

I don’t want to expose parent as public or pass it in the Item constructor because I want my hierarchy to be composed just using the method add (in real life a lot of things can lead to that decision).
With a friend I could just add this to Item:

// friend method
private function setParent(p) {
  parent = p;
}

But how do you call that safely from outside the Item class? It is private so it cannot be invoked directly … you can use untypedto make the compiler skip the types check on that call; but what happens if you want to change the name of setParent toset_parent at a later point and forget to change the untyped call too? The compiler will not spot the error and you’ll only catch it at runtime when some strange behavior will pop.

Here it comes the solution, change the Container.add function this way:

public function add(n : Item) {
  children.add(n);
  var p : { private function setParent(p : Container) : Void } = n;
  p.setParent(this);
  return n;
}

I have created a temporary var p whose type is exactly and only what we need to access the “friend” method. It works without any casting or untyped access because the type of “p” is structurally a sub-type of Item making it implicitly compatible. We can callsetParent from p because typedefs define a structure but do not impose any access limit.

Now the output is what expected at first:

Test.hx:7: [Container] has 2 children
Test.hx:8: [Item] John has 1 sibblings
Test.hx:9: [Item] Jane has 1 sibblings

If and when you will change the name of Item.setParent the compiler will throw an error notifying that Item is no more compatible with the type of p.
Many thanks to Nicolas Cannasse that suggested this unusual way of using typedefs on the haXe mailing list.