HaxeDoc2

14 }

15 }

16
17 class ImplicitCastField {
18 static public function main() {
19 var a:MyAbstract = " 3 ";
20 var b:Array=a;
21 trace(b); // [3]
22 }
23 }
By adding@:fromto a static function, that function qualifies as implicit cast function from its
argument type to the abstract. These functions must return a value of the abstract type. They
must also be declaredstatic.
Similarly, adding@:toto a function qualifies it as implicit cast function from the abstract to
its return type. These functions are typically member-functions but they can be madestatic
and then serve as selective function (2.8.4).
In the example the methodfromStringallows the assignment of value"3"to variablea
of typeMyAbstractwhile the methodtoArrayallows assigning that abstract to variablebof
typeArray.
When using this kind of cast, calls to the cast-functions are inserted where required. This
becomes obvious when looking at the Javascript output:
1 var a = _ImplicitCastField.MyAbstractImpl
2 .fromString(" 3 ");
3 var b = _ImplicitCastField.MyAbstractImpl
4 .toArray(a);
This can be further optimized by inlining (4.4.2) both cast functions, turning the output into the
please review your following:
use of “this” and try
to vary somewhat to
avoid too much word
repetition

please review your
use of “this” and try
to vary somewhat to
avoid too much word
repetition

1 var a = Std.parseInt(" 3 ");

2 var b =[a];

Theselection algorithmwhen assigning a typeAto a typeBwith at least one of them being an

abstract is simple:

1.IfAis not an abstract, go to 3.

2.IfAdefines ato-conversions that admitsB, go to 6.

3.IfBis not an abstract, go to 5.

4.IfBdefines afrom-conversions that admitsA, go to 6.

5.Stop, unification fails.

6.Stop, unification succeeds.

By design, implicit casts arenot transitive, as the following example shows:

1 abstract A(Int){

2 public function new() this = 0;

3 @:to public function toB() returnnew B();

4 }

5

6 abstract B(Int){