();
var type: Type = staticField.type;
// Extract the actual type if the type is TLazy
type = switch(type) {
case TLazy(_ => _() => actualType):
actualType;
case _: type;
}
var args = switch (type) {
case TFun(__args, _):
__args;
case _: throw "Error"; // static fields with @:op should always be functions
}
// skip the first argument - this
for (i in 1 ... args.length) {
var arg = args[i];
var isBaseType: Bool = (getAbstractRef(arg.t).toString() == baseAbstractRef.toString());
var newArgType: ComplexType = if (isBaseType) {
localComplexType;
} else {
Context.toComplexType(arg.t);
}
newArgs.push({
name: arg.name,
opt: arg.opt,
type: newArgType
// value?
// meta?
});
}
var name = staticField.name;
var newFunc: Function = {
args: newArgs,
ret: localComplexType,
expr: macro return this.$name(other)
// params?
}
fields.push({
name: staticField.name,
doc: staticField.doc,
access: [staticField.isPublic ? APublic : APrivate], // inherit access modifier
kind: FFun(newFunc),
pos: staticField.pos,
meta: staticField.meta.get()
});
}
return fields;
}
}
```
Usage:
```haxe
// Main.hx
package;
@:transitive
abstract A(Int) from Int to Int {
@:op(A + B)
public function add (other: A): A {
return (this: Int) + (other: Int);
}
@:op(A - B)
public function sub (other: A): A {
return (this: Int) - (other: Int);
}
}
@:transitive
@:build(ForwardOpsMacro.build("B", "A"))
abstract B(A) from A to A {}
@:build(ForwardOpsMacro.build("C", "B"))
abstract C(B) from B to B {}
class Main {
static function main() {
var a: C = 68;
var b: C = 1;
var c: C = a + b;
trace(c);
}
}
```
---
### Author:  [@kvbc](https://community.haxe.org/u/kvbc)
#### Post date: [April 8, 2023, 6:00pm UTC](https://community.haxe.org/t/help-creating-a-macro-to-forward-operator-overloads-solved-i-guess/3925/3 "2023-04-08T18:00:39Z")
Well, as it turns out, it’s not that simple.
The build order is unspecified, so… that’s a problem.
But I’ll be updating the macro here [GitHub - kvbc/haxe-macros: my haxe macros library](https://github.com/kvbc/haxe-macros/)
---
### Author:  [@player\_03](https://community.haxe.org/u/player_03)
#### Post date: [April 13, 2023, 3:27am UTC](https://community.haxe.org/t/help-creating-a-macro-to-forward-operator-overloads-solved-i-guess/3925/4 "2023-04-13T03:27:15Z")
Yeah, neither macro should rely on the other having run. If C happens to be built before B, drill down all the way to A and get the data from there.
By the way, you can simplify a bit. Haxe already knows how to add two integers, so all you need to do is tell it it’s allowed to do so.
```haxe
@:transitive
abstract A(Int) from Int to Int {
@:op(A + B)
private function add (other: A): A;
}
abstract B(A) from A to A {
@:op(A + B)
private function add (other: B): B;
}
```
---
### Author:  [@kvbc](https://community.haxe.org/u/kvbc)
#### Post date: [April 23, 2023, 6:03pm UTC](https://community.haxe.org/t/help-creating-a-macro-to-forward-operator-overloads-solved-i-guess/3925/5 "2023-04-23T18:03:25Z")
Yup, “drilling” is exactly what I did in my updated version.
- If **B** has been built before **C** ===\> There’s no problem. **B** took from **A** before **C** could build and take from **B** , so **B** already has **A**. In the end **C** has both **B** and **A**
- Otherwise, if **C** has been built before **B** ===\> **C** takes from **B** , and since it knows **B** ’s underlying type ( **A** ) and **B** has not yet been built - it takes from **B** ’s underlying type ( **A** )
Examples:
- Build order: **A** , **B** , **C** (most desirable)
- A \< Int
- B \< A
- C \< B
- Build order: **D** , **C** , **B** , **A** (insanity)
- D \< C — _“drills” through its underlying types, since **C** has not yet been built_
- D \< B
- D \< A
- C \< B
- C \< A
- B \< A
- A \< Int
I’ve built-in the visualization of this whole process in the updated macro in the github repository I’ve posted right above
# [Try it out online](https://try.haxe.org/#48F16312)
Example compiler output for the build order of **C** , **B** , **A**
