Humble Haxe, approaches to automating merging haxe within a non haxe friendly target project?

Question

Often with haxe we need to use existing non haxe code, so instead of writing externals we may want our haxe code to absorb parts of a system or add to it, a system where we can't assume a nice haxe setup.

For instance taking the js target suppose we want to add functionality to some existing javascript code, we can't easily control the entry point of haxe we have to inject functionality or classes within current js code. JS code which maybe too complex to rearrange into a really haxe friendly format. So one approach would be to mock up a class with stuff we need and then try to create some neko to automatically insert it and convert it, merging into the current codebase... but this is quite an open ended problem, and would differ with other targets.

So my question is what approaches have you developed for mixing in haxe target code within existing target code, for instance adding a haxe class within a js source, maybe using some neko to automate the insertion and rearrange the boot code needed for the haxe in the haxe class. But also interested in how you might approach this with other targets I probably have ideas for haxe flash but not say PHP or c++. Lets assume you can't setup the standard main boot structure, and on every publish you really would like your haxe code to be merged correctly back into the main non haxe project code when you hit the build button.

Tricky one but very important as solutions make it much easier to use haxe within more projects.

Answer 1

I've had only small amounts of experience with what you say, but here goes:

• JS - I've used a custom Markdown library (variant of mdown ), which was written in Haxe, in a predominantly non-haxe javascript environment. I tried to make it as "black box" as possible - the Haxe library exposed a static method using @:expose metadata , so I could call Markdown.convert(str); from anywhere in my Javascript. We found keeping it as "black box" as possible was beneficial, so the non-haxe Javascript knew what input to provide and what output was expected, but everything else was opaque.

• PHP - I've done one or two projects where I did some work in Haxe, and had to include it on an existing PHP website. I found I could piggy-back off the existing websites sessions to check that the user was authenticated, and I set up a way for the existing site to provide a "base template" for the Haxe portion of the app, which Haxe then rendered into. Pretty hacky, but it did the trick and meant the template for both the Haxe section and the non-haxe section was updated.

• Another approach for server-side could be separating out into user-facing code and an API. So perhaps Haxe sets up a JSON API, and the PHP talks to it. Or perhaps you have a Haxe website, and it talks to a Ruby/Python API etc.

So as you can see - I've tried to keep things pretty distinct. If Haxe can function in a relatively standalone manner, and interacts with other code by taking a particular input and providing a particular output, then things can behave relatively predictably. I haven't tried much further integration than that, I think the way Haxe works (using it's own class system and data structures etc) is different enough that tight integration could prove problematic.

Answer 2

I rarely mix code but here it goes:

• for flash you don't need anything, if you add your swf lib made in another program you can access the classes from haxe.

• for js is not possible without externs unless you want to use untyped. Or maybe you understood what Jason made, i didn't :)

• for cpp is even worse, you have to use cffi which will end up in a mess of code, for samples inspect how nme extensions work.

• never used java but i think here is simple