GOM binding for Javascript

[BrunoLevy]

Implement GOM bindings for Javascript (for instance, to have a Graphite viewer in emscripten, with controls programmed in JS, using nice widgets well integrated with the browser).

The plan

• compile Graphite with emscripten
• make it work in local installation
• create github action
• bind a couple of functions to JS for a first test
  • scene-graph functions
    • load object
    • delete object
    • rename
    • duplicate
  • a function to execute LUA code
    • void function
    • translate return type into JS
• GOM/JS binding

JS binding for GOM

Emscripten has an embind library, see how it can be adapted to GOM.

• Can we override member lookup in Javascript ?
  It seems so, see how embind maps getters and setters to attribute access, then member function lookup is just a getter that returns a closure. The magic is in _embind_register_class_property() defined in libembind.js. It uses Object.defineProperty (standard JS). So we can do that for each attribute and each member function at object creation (so at least we got something that will work). Can we do that generically ?
• Functions with varargs exist in Javascript, good ! (either ... syntax, or special args kw, see if args kw can be used in inline JS)
• It is possible to implement C functions in Javascript, as done in several Emscripten libraries (like OpenGL), details here

Understanding JS object model - Notebook

• JS objects have a "prototype". Understand similarities / differences with Lua and Python mechanics
• I can see a __lookupGetter__ and __lookupSetter__ method, smells very good ! ... Nope, seems to be deprecated, but there is Object.getOwnPropertyDescriptor(). Can it be overriden ? Is it used by method resolution internally ? Nope, does not seem to be the way to go, Proxy seems to be the thing (see below)
• Attributes that are not found in object are looked up from prototype, and from prototype's prototype, and so on and so forth
• It seems that what I want to do can be done with a Proxy. See also here.
• ... or by overriding the [[Get]] internal method (is it possible ? I don't think so, Proxy then ...)

Soooo, it may work as follows:

• GOM objects exposed to JS will have ptr to gom object and prototype, nothing special, plain JS
• prototype will be a Proxy around a single instance of a "JS gom meta class object"
• JS gom meta class object will know how to get/set. It will get the metaclass from the gom object. If it does not work, we can have a JS gom meta class object per gom class, would be less elegant
• There will be also a JS gom closure object for marshalling args. It will be what object method lookup will return.

Links

• embind / JS interop doc
• embind header (bind.h)
• embind source (bind.cpp)
• embind JS sources libembind.js libembind_gen.js libembind_shared.js