Giter Club home page Giter Club logo

napi's Introduction

Native-friendly API for Haxe targets

Write code in Haxe, distribute in native-friendly form.

Initiative

Haxe is great, one can write once and run the code in many targets. But it isn't very great as it is almost all-or-nothing. One either write the whole solution in Haxe or not use Haxe at all. Because it isn't really easy (but definitely not impossible) to mix Haxe with the native language in the same project.

There are a few reasons for that. One of the major reasons is that in order to standardize across targets, Haxe has created it own set of data types, some of which has quite different interfaces than the equivalent types on the native side. And this make it not so easy to communicate between Haxe and the native targets.

Also, Haxe is a garbage-collected language, which is another major obstacle for smoothly integrate Haxe into non-GCed targets like c++. Extra care is required in passing data across the bridge.

This project serves as an intiative trying to close the gap between Haxe and its native targets.

Goals

Data Type

The primary goal of this initiative is to provide common data types that are useful to both Haxe and Native developers.

For example, in Haxe/JS a Map is implemented as an object with a h key holding the key/value pairs, while on Haxe/Java & Haxe/C# it is a double array. Both of them are not very useful to a native developer.

For this particular problem, one of the possible solution is to use Proxy in JS to forward field access into the underlying h object. Or implement a wrapper over the Map (Java), IDictionary(C#) interfaces.

Function type and Enum are some another topics we defintely want to discuss.

Others

Here lists some of the extended goals that may worth discussion:

  • Making private functions private
  • Genenate native-friendly class from an ordinary Haxe class
  • Macro that generates the required header/wrapper/whatnot for c++
  • Documentations, tutorials, starter kits, etc
  • Toolkit for building, testing, packing binaries, submiting to central repositories, etc

Collaborations Welcome

This initiative requires experitize from each targets and couldn't possibly be done by a single person. So, any kind of collaborations will be more than welcomed, may it be a comment, idea, discussion, code example, test case, reference. Anything.

Experimental

For now, all codes inside this repo (if there are any) are deemed as experimental. Use at your own risk.

napi's People

Contributors

kevinresol avatar

Stargazers

Ben avatar 'Damilare Darmie Akinlaja avatar  avatar timothy eichler avatar Jonas Nyström avatar Jens Fischer avatar Marcelo Serpa avatar Anders Nissen avatar Jesse Talavera avatar Ben avatar  avatar

Watchers

James Cloos avatar 'Damilare Darmie Akinlaja avatar  avatar Ben avatar

Forkers

benmerckx

napi's Issues

Clarification: Communication between Haxe and native targets

There are a few reasons for that. One of the major reasons is that in order to standardize across targets, Haxe has created it own set of data types, some of which has quite different interfaces than the equivalent types on the native side. And this make it not so easy to communicate between Haxe and the native targets.

Can you enumerate these differences? Where do you get into trouble? I am not aware of such problems. It would be helpful to see some examples.
And how would you solve these problems?

Native libraries project formats

Information about each target's native project format and library distribution format.
For use in the toolchain. (Auto create native project, submission helpers, etc).

Target Project Format Distribution Format Repo / Manager Getting Started Submit
JS/Node.js package.json source npm npm init npm publish
C# .nuspec dll NuGet
Java gradle, buck jar, aar maven, jcenter
Python ? source pip
Lua ? source LuaRocks
C++ ? source
static/dyn lib
?
AS3 ? source, swc ?
PHP composer.json source composer composer init packagist.org

Note: If anyone knows the missing information, please comment below and I will update accordingly.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.