Design question

[jcswart]

Hi,

Question from someone learning V8 and deno_core and using your repo.

I'm wondering, purely for learning purposes why you used the op_return, __rust_return and ResourceTable as the means for getting values back from deno_core?

I've noticed that when I create my own ops using deno_core directly I often get values back as v8::Global<T> and then I hit a brick wall, this value does not seem useful for getting at the underlying value generated from executing the javascript in deno.

Is this the reason for your design decision?

Were there others you considered or know of?

Thanks for you time. Your repo is extremely useful for seeing something minimal and practical done with deno_core.

[Bromeon]

At the time I first looked into deno_core, this seemed like the most straightforward way. My thought process was:

deno_core is designed to call Rust functions from JavaScript. How can I use this mechanism to do the opposite and call JavaScript from Rust? If I use ops as functions to submit the return value, how could I pass in the function arguments?

And this led to the current design, with "eval-style" code strings for the arguments and ops for the return values.

That said, I haven't followed up new deno_core APIs very closely, so it's possible that there are other (better?) ways of doing that.

[Bromeon]

Marking as answered.