IDEA: Is api really easy? about spidermonkey_runtime HOT 14 OPEN

You're right, register_op was one of the first things i got working, a lot has changed since then. I'll look into changing this in this issue.

Thanks for the tip!

from spidermonkey_runtime.

What about esses.invoke_rust_op_sync?

from spidermonkey_runtime.

well on the rust side i'd like to refactor it to work like this

rt.add_function("my_function", |args: Vec<EsValueFacade>| {
    EsValueFacade::new_str("a value".to_string())
});
// or
rt.add_function("com.my_org.MyObj.my_function", |args: Vec<EsValueFacade>| {
    EsValueFacade::new_str("a value".to_string())
});

this will add 2 native functions to the root or the package in the script engine
e.g. (or should we add sync/async optionally with an extra boolean param?)

• my_function -> Promise
• my_functionSync -> Value

so in script you can do:

let aPromise = my_function(1, 2, 3);
// or
let aValue  = my_functionSync(1, 2, 3);

implementing this will be quite easy with the current Utils i have

the closures can be added to a HashMap by name and that name will also be set as a permanent property to the JSFunction objects created in the scope

The JSFunction will point to a native method which will check the property of the callee object (which will be the JSFunction) and so we can get the closures from the map and invoke them...

from spidermonkey_runtime.

this example:

rt.add_function("com.my_org.MyObj.my_function", |args: Vec<EsValueFacade>| {
    EsValueFacade::new_str("a value".to_string())
});

could also be done with a Proxy, but currently i'm unsure how to proceed with the 'Easy' variant EsProxy... the problem was that i don't really want the 'Easy' code to run in the worker thread of the engine but that would mean you can only have methods that return a Promise... i'm tempted to place some responsibility on the 'Easy' dev afterall and just document that you need to be carefull about running long running code in sync methods...

from spidermonkey_runtime.

one last note: about the sync/async variants

i'd really like async functions to be the "normal" way to implement functions.

We could also implement add_function to simply add one function and put the responsibility of returning a Promise on the devs shoulders but i'm afraid that may lead to people just doing everything sync... what do you think?

from spidermonkey_runtime.

What about using procedural macros. Something like servo is using just without webidl and codegen. It make sense that struct is then JS object and methods are its functions. And with procedural macros I think we can achieve to return a Promise even if original function is meant to be sync.

For choosing between async and sync funcion it could be like:

let aPromise = sync.my_function(1, 2, 3);
// or
let aValue  = async.my_function(1, 2, 3);
// or import function to global (you can import sync or async function to global)
import { my_function } from async
let aPromise = my_function(1, 2, 3);

from spidermonkey_runtime.

Or maybe turn that around?

let aPromise = my_function(1, 2, 3);
let aValue = my_function.sync(1, 2, 3);

Then again it would make adding simple sync util methods complex...

from spidermonkey_runtime.

Wrong button 😀

from spidermonkey_runtime.

i'm tempted toward just having two functions in rust

rt.add_function("my_function", |args: Vec<EsValueFacade>| {
    EsValueFacade::new_str("a value".to_string())
});
// and
rt.add_sync_function("my_other_function", |args: Vec<EsValueFacade>| {
    EsValueFacade::new_str("a value".to_string())
});

in which case the "normal" function returns a promise and you need to use the sync rust variant to add a sync function to JS

let aPromise = my_function(1, 2, 3);
let aValue = my_other_function(1, 2, 3);

Naming them so they tell the user what they do is up to common sense of the dev...

from spidermonkey_runtime.

i'd also like to figure out how to use generics and/or traits so you could just write

rt.add_function("my_function", |args: Vec<EsValueFacade>| {
    "a value" // or 123 // or true
});

and do the conversion to EsValueFacade behind the scenes

from spidermonkey_runtime.

More like:

let aPromise = my_function(1, 2, 3);
let aValue = sync.my_function(1, 2, 3);

and as for rust functions I would make even input args a rust type, maybe something like:

#[jsfn]
pub fn print(s: String) {
      println!("rust said: {}", s)
}

and there is also rjs. Which is very similar to es_runtime. There is an interesting way of handling functions.

from spidermonkey_runtime.

More like:

let aPromise = my_function(1, 2, 3);
let aValue = sync.my_function(1, 2, 3);

would that not just enable people to run ops sync while they realy should not be doint that.

if the js dev wants easier notation he could just use await in an async function

async function do_something() {
    let aValue = await my_function(1, 2, 3);
}

and as for rust functions I would make even input args a rust type, maybe something like:

#[jsfn]
pub fn print(s: String) {
      println!("rust said: {}", s)
}

although i like the shortness i dislike the lack of controll as in which runtime/module/scope do i add this method to...

i'd like to stick to this for now also because i'm not that handy with macro's yet

rt.add_function("my_function", |args: Vec<EsValueFacade>| {
    "a value" // or 123 // or true
});

and there is also rjs. Which is very similar to es_runtime. There is an interesting way of handling functions.

ooh, lot of ideas to be found there :) .. i'll check it out

from spidermonkey_runtime.

More like:

let aPromise = my_function(1, 2, 3);
let aValue = sync.my_function(1, 2, 3);

would that not just enable people to run ops sync while they realy should not be doint that.

if the js dev wants easier notation he could just use await in an async function

async function do_something() {
    let aValue = await my_function(1, 2, 3);
}

This was instead of my_function.sync() from #15 (comment).

and as for rust functions I would make even input args a rust type, maybe something like:

#[jsfn]
pub fn print(s: String) {
      println!("rust said: {}", s)
}

although i like the shortness i dislike the lack of control as in which runtime/module/scope do i add this method to...

i'd like to stick to this for now also because i'm not that handy with macro's yet

rt.add_function("my_function", |args: Vec<EsValueFacade>| {
    "a value" // or 123 // or true
});

To control module or scope proc_macro arguments could be used. Something like in wasm-bindgen.

#[jsfn(namespace = test)]
pub fn print(s: String) {
      println!("rust said: {}", s)
}

and then you call it like test.print(""). The syntax that is used in wasm-bindgen for to JS exports is pretty good and widely used, so I think it would be good to use it in es_runtime too.

from spidermonkey_runtime.

Hmm, i like it.. Gonna work on soms basics and then work towards this.. thx

from spidermonkey_runtime.