Extendor Construct

[Xonok]

I've created a code construct that runs after the whole vJASS preprocessor(or before it, but that's not preferable).

Essentially it works like this:
There are blocks that start with //# extendor and end with //# endextendor.
There are also single-line calls that start with //# runextendor.
Each extendor is named.
Each extendor has a priority(0 if undefined)

When the map has been saved, all extendor blocks are combined into chunks based on name(blocks with the same name are combined together).
Then every runextendor line is replaced with the appropriate block.
If necessary, parts of a block are organized based on priorities. Blocks with lower priority numbers are placed first.

So the formats are:

//# extendor NAME [PRIORITY]
    //code
    //more code
//# endextendor

//# runextendor NAME

When extendor blocks are compiled, then the leading whitespace+// is removed from code inside the blocks. Commenting code out is necessary because otherwise the vJASS preprocessor would throw errors.
If you want to use comments inside extendors you need to use another //.
Multiline comments are handled entirely by the vJASS preprocessor, so extendors don't even know of their existence.

Possible uses:
*A projectile system where collision handlers do not need to be defined as triggers. Callback efficiency varies, as at some point it is cheaper to run a trigger than to do a bunch of if-then-else cycles for finding out the proper handler.
*A damage handler for a damage detection system such as the one by looking_for_help. Adds priorities with 0 code overhead.
*Coding events with no code overhead.(unit indexers,damage detection systems,ability managers, among other things)

Thinking about this feature further I have concluded that several vJASS features are partially or entirely subtypes of this construct:
*Globals blocks - Place one runextendor line in the globals block of the war3map.j and add to it with extendors. Identical functionality.
*Text macros without arguments - Define blocks of code with extendor blocks and run with runextendor. Functionality is identical.
*Modules without scoping - Same as text macros.
*Libraries(code organization) - A single runextendor line for the whole map with one extendor block per library to add to it. Libraries work better in this case.

Download from pastebin.

Warning. I do not guarantee that this feature is bug-free or that I will fix it if it doesn't work right or that it will work out of the box like it does for me. I am however willing to help in getting it to work and change/add features when I find it appropriate to do so.
Purposefully breaking the feature does not prove a point to me, as this is not a fully foolproof code construct and was never meant to be such.
I am also not responsible in any way if this construct breaks your JNGPE installation, crashes the editor, destroys your map, targets a nuclear bomb at your house, kills your cat or does anything else that you may find undesirable.

EDIT: Current version is a bit buggy. I'm fixing it as soon as I can.
EDIT2: Not buggy. I'm just an idiot at using my own code.

 

[WaterKnight]

Sounds like injection/hooks. I have made something similar

module Allocation
	static method allocate_mount takes thistype this returns thistype
		injectTarget hook

//! inject Allocation.allocate_mount.hook
	set this.$varName$ = $default$
//! endinject

But I only used it for system-relevant stuff so far. As you can see it is supposed to be done before jasshelper since I wanted to push vjass code.

May I advertize for my new framework? The downside is that your tool needs to be activated by writing somewhere in the code the line

//! post Extendor args

If you want it after jasshelper, it's

//! noJasshelper

//! post Jasshelper --debug jasshelper\common.j jasshelper\blizzard.j $MAP$

//! post Extendor $MAP$

also the tool needs to be defined in jasshelper.conf.

The upside is that we do not need a new wehack.lua for more tools/each combination thereof. Also the processed map is a copy of the one you save in the editor, so it's less likely the individual tool destroys stuff permanently + they are allowed to do finalizing tasks like throwing away editor-only data.

 

[Xonok]

Actually it would be ideal to have it run after //! import lines, but before any syntactical changes to the code. I think it's not the same as running after JassHelper.
That would allow using the local names of variables even if they are scoped and thus, it would also allow variable renaming if parameters are provided.

 

[WaterKnight]

//! import can quite easily be resolved without jasshelper. That's what I am doing in my preprocessor initially, too.

 

[Xonok]

Alright, in that case I can use your approach to fix some current issues(having to use the final variable names, as outputted by JH).
How would I make the import step without JH then? Do you have a lua script for that?

 

[WaterKnight]

Not as standalone but I can forge you something later this day or tomorrow.

edit:

exttools\vjassImport\

line to add to jasshelper.conf [externaltools]:

"vjassImport","exttools\\vjassImport\\vjassImport.exe"

In jass code write:

//! noJasshelper

//! post vjassImport $MAP$

//! post Jasshelper --debug jasshelper\common.j jasshelper\blizzard.j $MAP$

preferably in the header. Things are still ugly and insecure.