Q: Can a build macro add a 'public static macro function' to a class? (currently, it seems no)

[Jeff Ward]

Hi,

I'm trying to add a macro function to a class from with a build macro. I understand that this is a little meta, and it's not currently working, so I'm guessing that the macro parsing step (or some macro cache) has me blocked in this.

Note that I've tried adding a macro field, and modifying the expressions in an existing macro field, and neither approach works.

Here's my test code: http://hastebin.com/uwozutixec.coffee

Does anyone know if this is possible, or perhaps it's simply not?

What possible use case would this have? Method overloading. I'd like to rename all same-name methods (done), store off the signatures (done), and then create a macro function of the original name (cannot do) that rewrites calls to the appropriate function signature.

Thanks,

-Jeff

[Nico May]

I'm probably confused, and I know very little about macros, but why do you need it to be a macro function? can't you just have a normal function that reroutes the calls?

Nico

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

[Jeff Ward]

Good question. If you wrote a normal function to do the routing, it would take dynamic arguments, determine their type, and call the right function. It'd work. All at runtime.

The macro does the same thing, except all at compile time. So you get type safety - the compiler won't let you call the function with parameters for which there isn't an implementation.

[Nico May]

hmm, so the macro function would directly route calls without an extra function call at all? I see how that could be different then, unfortunately I can't help you :/

On Thu, Jun 9, 2016 at 8:09 PM Jeff Ward <jeff...@gmail.com> wrote:

Good question. If you wrote a normal function to do the routing, it would take dynamic arguments, determine their type, and call the right function. It'd work. All at runtime.

The macro does the same thing, except all at compile time. So you get type safety - the compiler won't let you call the function with parameters for which there isn't an implementation.

[Juraj Kirchheim]

Long story short: you can't generate macros in a build macro and even if you could, you most certainly would not be allowed to override methods with macros.

Example:

  class Foo { function foo():Void {} }

  class SubFoo { override macro function foo():Void {} }

  var foo:Foo = new SubFoo();

  foo.foo();//<-- override cannot have any effect

Could you back up a little and explain the particular problem you're trying to solve?

Best,

Juraj

[Jeff Ward]

Hi Juraj,

I'll post more details later -- but basically I want to implement method overloading in Haxe by renaming and mapping the functions in a macro. And it's working (currently just for static methods.) The fact that I wanted to generate a macro is a convenience -- without it, you have to paste a small one-line macro method next to your overloaded functions. Here's what's working currently:

#if !macro @:build(Overload.setup_overload()) #end

class Test

{

#if !macro

  public static function add(a:Int, b:Int):Int { return a+b; }

  public static function add(a:Int, b:String):String { return a+b; }

  public static function add(a:String, b:Int):String { return a+b; }

  public static function add(a:String, b:String):String { return a+b; }

  public static function add(a:String, b:Foo):String { return a + b.name; }

#end

  public static macro function add(params:Array<haxe.macro.Expr>):haxe.macro.Expr {

    return Overload.do_overload('Test', 'add', params);

  }

}

Best,

-Jeff