JS backend should be more liberal about typing

[Manishearth]

I think the JS backend should accept objects with the right fields in lieu of struct types, and strings in lieu of enum types.

Basically, if a method method accepts struct Struct {a: Enum, b: u32} where Enum has variants Foo, Bar, it should also be acceptable to invoke it with method({a: "foo", b: 1}).

The easiest way to do this is probabyl give every enum and non-out struct a constructor that acceps either the looser typed version, or an instance of itself, and unconditionally call the ctor before doing any JS-to-C shenanigans

[Manishearth]

Similarly, we need toString on all enums

[Manishearth]

cc @ambiguousname UX of the JS API is probably an interesting thing to hack on, and probably not too involved.

Writing tests is a good way to discover these UX pitfalls, too.

[ambiguousname]

That would be interesting! I agree, I think this would be fairly easy to set up in the JS API. I really like the idea of checking an object for the right fields inside of our methods instead of being so strict about what we pass in. That would allow us to remove some of the more clunky elements of the API (like _intoFFI).

And yes, lots of tests would be great.

(Edit: Manish's comment below is right, _intoFFI is still a necessity)

[Manishearth]

at would allow us to remove some of the more clunky elements of the API (like _intoFFI).

we still would need _intoFFI i think!

[Manishearth]

I think no matter what once we have a bag of stuff we need some way to share code on how that bag of stuff gets converted to something FFI-compatible. I think _intoFFI()-style methods are actually good for this kind of thing: we always need to turn whatever freeform type we have into an object of the right concrete type (which we can teach the ctor to do, or potentially some static method), and then that type has a convenient method.

[ambiguousname]

Mostly I'm annoyed at the _ in the function, The pseudo-privateness feels really wrong to me. If we made it a static function (static intoFFI()), then that would give us wiggle room to allow any object passed to us with the right members.

[ambiguousname]

It also gives the added benefit of cleaning up intoFFI, as we'd need to check for the existence of each member in the object. Then that makes it super easy to read what intoFFI does. For instance, something like:

static intoFFI(object) {
  var array = [];
  if ("a" in object) {
    array.push(diplomatRuntime.someConversionFunction(object.a));
  } else {
    throw new Error("...");
  }
  return array;
}

[Manishearth]

Mostly I'm annoyed at the _ in the function, The pseudo-privateness feels really wrong to me. If we made it a static function (static intoFFI()), then that would give us wiggle room to allow any object passed to us with the right members.

I think we can make it properly private via a symbol, it should be [diplomatRuntime.intoFFI]: instead of intoFFI().

I still think it should be a method, if we want a higher level constructFromAnything() we can make it too. I think that method should just be the constructor.