including modules about gen_js_api

[alainfrisch]

Note that the .mli is not valid in itself: include Event refers to a non-existent module type Event. A valid OCaml interface would be:

module MouseEvent : sig
  include (module type of Event)
  val alt_key: ...

(Note also the removal of the definition for type t, which clashes with the imported one.)

But this would have the effect of defining MouseEvent.t as an alias for Event.t, which is not the intention I guess (the methods in MouseEvent should not apply to values of type Event.t).

Here are several approaches to described such hierarchies with gen_js_api:

• Define MouseEvent.t as an abstract type, with explicit coercion function to/from Event.t. You can also re-export manually methods for Event in MouseEvent.

• Flatten the hierarchy, i.e. expose everything in module Event. I suspect that the OCaml side of your application will introduce some higher-level concepts above the raw DOM APIs, and these layers would be responsible for exposing a more typeful interface to the applicative code. See e.g. our ocaml-vdom package for such a case.

• Use OCaml objects and inheritance (https://github.com/LexiFi/gen_js_api/blob/master/CLASSES.md), although I'm personally not a big fan of this approach (it adds a lot of weight to the generated code, and probably some non-negligible runtime overhead).

[nickbetteridge]

Excellent - thanks for your time in writing the above - coercion seems the easiest route, but ocaml-vdom looks very interesting. And thanks for correcting the elementary ocaml mistakes! Final thanks for making gen_js_api available - made my life considerably easier.