Could someone explain HaXe enums?

Question

I have AS3/PHP background and some basic understaning of enums from C++. Saying shortly: I read this:

http://haxe.org/ref/enums

http://haxe.org/doc/cross/more_on_enum

And though - good heavens! What the sorcery is this???

Enum Constructors Parameters? Enum Type Parameters??

Could someone explain with working examples (preferable on http://try.haxe.org/ ) the concept of enums in HaXe for someone coming from languages like PHP and AS3?

What I tried?

Firstly I wrote this:

enum Color3 {
    Red;
    Green;
    Blue;
    Grey( v : Int );
    Rgb( r : Int, g : Int, b : Int );
    Alpha( a : Int, col : Color3 );
}

Then this:

Color3.Grey(5);

And I don't know what to do with this further, and don't know where to search.

Answer 1

HaXe enums are algebraic data types (ADTs). Your example in Haskell:

data Color3
  = Red
  | Green
  | Blue
  | Grey { v :: Int }
  | Rgb { r, g, b :: Int }
  | Alpha { a :: Int, col :: Color3 }

In either language, this type simply expresses that a Color3 has a few possible values—red, green, or blue; a grey value; an arbitrary RGB value; or a Color3 value with an additional alpha channel. The fact that some of these constructors take extra parameters should not be alarming. It is simply a terse closed analog to the open behaviour of inheritance:

class Color3 {}

class Red : Color3 {}
class Green : Color3 {}
class Blue : Color3 {}

class Grey : Color3 {
  public var v:int;
  public function Grey(v:int) {
    this.v = v;
  }
}

class Rgb : Color3 {
  public var r:int, g:int, b:int;
  public function Rgb(r:int, g:int, b:int) {
    this.r = r;
    this.g = g;
    this.b = b;
  }
}

class Alpha : Color3 {
  public var a:int;
  public var col:Color3;
  public function Alpha(a:int, col:Color3) {
    this.a = a;
    this.col = col;
  }
}

Here anyone can come along and add a new Color3 child class that may or may not respect the properties we want to enforce. With parameterised enums we have central control over all the constructors, and we also have pattern matching:

return switch (c) {
  case Red: 0xFF0000;
  case Green: 0x00FF00;
  case Blue: 0x0000FF;
  case Grey(v): (v << 16) | (v << 8) | v;
  case Rgb(r,g,b): (r << 16) | (g << 8) | b;
  case Alpha(a,c): (a << 24) | (toInt(c) & 0xFFFFFF);
}

Contrast the alternative of adding a toInt() method to every subclass of Color3. It would be much more code, leading to more potential for errors.

Note that this particular example isn’t great because a few of the constructors are redundant: Rgb subsumes Red, Green, Blue, and Grey, and Alpha can be applied to a colour that already has Alpha, which may not be desirable.