Abstracting Data Types

[Oguz Bastemur]

Reasons;

• Local, Handle, Persistent... is not that easy to use (learning curve for native addon development)
• Other engines do not have a similar typing / rooting
• It's easy to make a mistake that can crash an application unexpectedly.

There are alternative solutions (including the one we use with jxcore native interface).

Abstracting data types alone doesn't cover all the type related future VM / version changes ( typeof differences / multi context instanceof reference problems etc) However, IMHO it is an important actor and decisive to all the other definitions.

[Colin Ihrig]

This seems logical. Could you go into more detail about:

There are alternative solutions (including the one we use with jxcore native interface).

[Trevor Norris]

If you'd like, make the file native/data_types.md and write out how you think this should be implemented. Then throw it up in a PR.

For now we'll be pretty loose with merging stuff in. Then once there are more opinions, discussions can be had about the existing docs and what changes should be made.

[Trevor Norris]

Or if you'd like just throw it in a gist and I'll land it for you.

[Oguz Bastemur]

@cjihrig @trevnorris Okay. I'm working on it.

[Michael Dawson]

Looking at the initial types in https://github.com/nodejs/api/blob/master/native/data_types.md and in particular:

struct JSValue {
  void* env_;
  void* data_;
  uintptr_t flags_;
};

We may find that we need to bundle the env_ into more than just the JSValue and possibly extend beyond a single pointer, so pulling out its definition into its own struct might make sense.

I also think making the structures opaque, and limiting access through helper methods would leave as more flexibility to change under the covers.

[Trevor Norris]

pulling out its definition into its own struct might make sense.

Have an idea what would go into that struct, or should there simply be a placeholder?

[Michael Dawson]

I think for now it would just be void* _env.

As to what might go there later some things that come to mind
1) the original description of _env sounds like it would point to java script engine (ex v8) structures. We might also need something at the Node or libuv level
2) It might be the place to add function pointers for the API (less sure on this front)

[Oguz Bastemur]

1. the original description of _env sounds like it would point to java script engine (ex v8) structures. We might also need something at the Node or libuv level

@mhdawson Why JSValue is related to other parts of the Node?

[Michael Dawson]

@obastemur I think this work is going to be pulled into the work that @stefanmb and @ianwjhalliday are pushing forward. Do you think we still need this issue.