Macro order & getting the tree of the whole file

[Cara Moun]

Hello,

In a desire to simplify and type some interactions between a client-server project I tried to dive into macros.

The code manipulation part is working for me but i'm stucked with how to do certain things at a higher scope than just a Class.

I'm a bit tired of annoying ousado on that matter so i'm asking here.

My first issue is Macro order :

I don't know how the typing works, but after reading a bunch of threads it seems like this is what makes the order of macro execution unreliable.

So a sample of my case would be : i need to catch every occurence of X metadata expression and then grab some datas from it to put them in an array A (just at the macro level and as a cache between macro executions); I'm then catching Y metadata expressions process them and use A to change the expression at Y, and even a third step...

Or basically, thinking in term of passes : catching datas at X THEN processing and pasting those datas at Y THEN ...

It seems inherently impossible to do that the *normal* way, but how would YOU do that ? can i parse & process the tree of the whole file ? several times ? how ?

Second issue related to above on how to process a whole file :

If i need to catch every occurence of X within a file without having to @:build every class, can i parse the whole file ? Is there a macro for this ? *cough cough*

Thanks.

[Juraj Kirchheim]

As a general rule of thumb: when you're trying to move information
around through macros in a way that seems impossible because of
evaluation order, chances are, you're implementing something like
COMEFROM (http://en.wikipedia.org/wiki/COMEFROM).

And even if it's not half that crazy, you should consider that if you
want these kind of super-global transformation rules, you really risk
of running into incompatibility with others. Of course, if you're 100%
happy with being a lone wolf programmer, that's not an issue.

The rationale is, that all macros are triggered by some explicit
mention. Either as a command line argument, or as a
@:build/@:autoBuild argument. Or as a "direct" macro. With that
restriction, two heavily macro based libraries can quite peacefully
coexist in a single project.

As for semi-automagical, the @:autoBuild-approach is usually the most
popular one. You declare an empty "marker" interface, that has the
@:autoBuild, and then triggering the magic becomes as easy as
implementing that interface.

----

As for parsing files: You can use Context.getType or Context.getModule
to get the parsed and typed information (assuming you know where to
look). But I think you will have to grab a nightly to recover
metadata, because Haxe has only lately started to preserve it in the
typed AST. Of course if you only need member/class metadata, then this
already works.

Regards,
Juraj