no voy a publicar ningún code
pero lo que deja de hacer aquí en estas respuestas es rima poner a la razón. Estoy trabajando en la arena JS nativa y surgió el problema de que algunos native API calls
necesitan ser transformados porque no podemos escribir en los parámetros sin feos hacks vergonzosos.
Esta es mi solución:
// Functions that return parameter data should be modified to return
// an array whose zeroeth member is the return value, all other values
// are their respective 1-based parameter index.
That doesn't mean define and return every parameter. Only the parameters that recieve output.
La razón de este enfoque es así: Multiple return values
puede ser necesaria para cualquier número de procedimientos. Esto crea una situación en la que los objetos con valores con nombre (que en última instancia no estarán sincronizados con el contexto léxico de todas las operaciones), constantemente, deben ser memorizados para poder trabajar de manera apropiada con el procedimiento (s).
Utilizando el método prescrito, es suficiente con saber what you called
, y en lugar de where you should be looking
tener que saber lo que está buscando.
También existe la ventaja de que los "robustos y estúpidos" alogrithms se pueden escribir para envolver alrededor de las llamadas de procedimiento deseadas para hacer esta operación "más transparente".
Sería aconsejable utilizar una object
, function
, o un array
(todos los cuales son objetos) como parámetro "write-back-producto", pero yo creo que si cualquier trabajo ajeno se debe hacer, lo que debería se debe hacer por el que escribe el kit de herramientas para facilitar las cosas o ampliar la funcionalidad.
Esta es una respuesta única para cada occaision, que mantiene el aspecto de APIs
a primera vista, en lugar de parecer ser y tener toda la semejanza de un tejido de código de spaghetti con un entramado indefinido que no puede descifrar si es una definición o datos.
Enhorabuena y buena suerte.
Estoy usando el webkitgtk3 e interconecto algunos proxios nativos de C Library. por lo que esta muestra de código probado podría al menos servir al propósito de ilustración.
// ssize_t read(int filedes, void *buf, size_t nbyte)
SeedValue libc_native_io_read (SeedContext ctx, SeedObject function, SeedObject this_object, gsize argument_count, const SeedValue arguments[], SeedException *exception) {
// NOTE: caller is completely responsible for buffering!
/* C CODING LOOK AND FEEL */
if (argument_count != 3) {
seed_make_exception (ctx, exception, xXx_native_params_invalid,
"read expects 3 arguments: filedes, buffer, nbyte: see `man 3 read' for details",
argument_count
); return seed_make_undefined (ctx);
}
gint filedes = seed_value_to_int(ctx, arguments[0], exception);
void *buf = seed_value_to_string(ctx, arguments[1], exception);
size_t nbyte = seed_value_to_ulong(ctx, arguments[2], exception);
SeedValue result[3];
result[0] = seed_value_from_long(ctx, read(filedes, buf, nbyte), exception);
result[2] = seed_value_from_binary_string(ctx, buf, nbyte, exception);
g_free(buf);
return seed_make_array(ctx, result, 3, exception);
}
Nick, Sé que fue hace un tiempo, pero creo que finalmente tengo una [respuesta] (https://stackoverflow.com/a/48517986/1016343) para ti. Sí puede hacer parámetros en JavaScript. – Matt