You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- Make the core C++ library an extensible base for developers to build on using different languages.
5
+
- Port features previously segregated to Javascript into C++, thereby removing dependency on JS for the core library.
6
+
- Move business logic into C++, thus allowing the purpose of the JS library to act as a bound wrapper rather than a dependent extension.
7
+
8
+
This document aims to elaborate on the design of the core library API, as well as information designed to aid the core developer in creating new features/extending the library into new language bindings.
9
+
10
+
### Components
11
+
- Table: C++ class that will implement the features previously found in the `perspective.js` table, including all prototype methods and class members.
12
+
- t_table: C++ class that manages the underlying operations for `Table`.
13
+
- View: C++ class that will implement all features and members previously found in the `perspective.js` view.
14
+
- pool: A collection of `gnode`(s) managed in C++.
15
+
- gnode: A "graph node" that contains any number of `t_table`s, although in implementation we only assign one `t_table` to one `gnode`.
16
+
17
+
### Steps for porting
18
+
1. Transliterate JS to C++: liberal use of `embind` and `val` in order to start porting features previously segregated to Javascript into C++.
19
+
2. Make C++ functions portable: start removing the use of all JS-dependent data structures, members, and methods in order to allow for C++ portability.
20
+
3. Add the translation layer: now that C++ functions expect generic C++ parameters (and not a `val`, on which any number of arbitrary JS-only operations may be called), add the translator layer that converts JS input into what the portable C++ API expects, as well as converts the output into something suitable for JS.
21
+
4. Convert the JS library into simple function calls: though the `perspective.js` API will not change, the underlying implementation for methods will simply return the output of the C++ method, with translation where necessary.
22
+
23
+
### C++
24
+
`View`: class which will implement all methods from the `perspective.js` version of view.
25
+
- Expects C++ data structure input and returns native data structures.
26
+
- Should be as portable and extensible as possible.
27
+
- Should abstract away concepts like pool and gnode.
28
+
29
+
`Table`: class which implements all methods from the `perspective.js` table.
30
+
- Expects C++ data structure input and returns native data structures.
31
+
- Should be as portable and extensible as possible.
32
+
33
+
### Translation/Helper layer
34
+
`make_view`: helper function in `emscripten.cpp` that returns a `std::shared_ptr<View<CONTEXT_T>>`.
35
+
- Should construct the underlying `View` object.
36
+
- Should expect native C++ data structures as input.
37
+
38
+
*TBD: how should we implement the translation layer?*
39
+
- As separate methods that are called, which makes `make_view` extremely dependent on side-effects?
40
+
- As a layer in `perspective.js`, which makes it harder to create C++ native data structures?
41
+
- As a new binding in the C++ `src` folder, allowing for a place for developers to add their own language bindings?
42
+
43
+
### Javascript
44
+
`View`: the view class on the Javascript side should be a wrapper around calls to the Emscripten `__MODULE__`.
45
+
- Should maintain an internal reference to the C++ `View` object created on instantiation.
46
+
- Methods should call the corresponding method on the C++ `View`, and return output that is ready for JS consumption.
0 commit comments