Bindings with interface languages

[dbrattli]

For languages that supports interfaces (or abstract base classes) the "normal" way of writing bindings leaves another interface around e.g:

type IExports =
    abstract dumps: obj: obj -> string
    abstract loads: string -> obj

[<ImportAll("json")>]
let json: IExports = nativeOnly

Will give the following in e.g Python:

class IExports(Protocol):
    @abstractmethod
    def dumps(self, obj: Any) -> str:
        ...

    @abstractmethod
    def loads(self, __arg0: str) -> Any:
        ...

So the question is what to do with it:. Should I leave it around or try to get rid of it. I tried this but gives error: nativeOnly is being compiled without replacement, this will fail at runtime.:

[<ImportAll("json")>]
type IExports =
    abstract dumps: obj: obj -> string
    abstract loads: string -> obj

let json: IExports = nativeOnly

So perhaps import both, but that seems redundant:

[<ImportAll("json")>]
type IExports =
    abstract dumps: obj: obj -> string
    abstract loads: string -> obj

[<ImportAll("json")>]
let json: IExports = nativeOnly

Maybe just erase it. This looks like a better way:

[<Erase>]
type IExports =
    abstract dumps: obj: obj -> string
    abstract loads: string -> obj

[<ImportAll("json")>]
let json: IExports = nativeOnly

For interfaces that represents real objects in the bound runtime, then it looks good to use an import instead to erase it, since the type will then represented correctly when transpiled:

[<Import("AST", "ast")>]
type AST =
    abstract foo: int

[<Erase>]
type IExports =
    /// Parse the source into an AST node
    abstract parse: string -> AST

[<ImportAll("ast")>]
let ast: IExports = nativeOnly


let a = ast.parse "test"

This will give the right type represented:

import ast
from ast import AST

a: AST = ast.parse("test")

Is this the right way to think about it, or?

[ncave]

@dbrattli For the few bindings I've done for Rust so far, I've mostly used Erase to remove the interface, e.g.:

[<Erase; Emit("std::time::Duration")>]
type Duration =
    abstract as_millis: unit -> uint64
    abstract as_secs_f64: unit -> float

Not sure if that helps you or not. I agree it would be nice to try to have a more standardized approach to bindings across all languages.
For Rust, I don't think we have decided yet what is the best way to generate bindings with a tool (e.g. something like rust2fable).

[alfonsogarciacaro]

We've gone through the discussion about using always interfaces for the bindings and unfortunately the conclusions are split in different issues, but I can try to summarize from memory:

• We chose to use interfaces only (with one interface for instances and another for constructor/static members) for Fable.Browser bindings because they were more flexible, allowed multi-inheritance (which is needed by some types in Browser APIs) and reflected more closely how the TypeScript declarations were originally written. The main drawback is users need to use Create for constructors. We're sticking to this model for consistency.
• In recent discussions (e.g. Flutter bindings) we're considering the idea to use classes instead. This works nicely with the new open type statement and I also realized recently static classes can be also decorated with AutoOpen. The bindings are a bit more verbose but not much (though users need to remember to write the type annotations including return to avoid automatic generalization).

So in your first example @dbrattli you could use:

[<ImportAll("json")>]
type json =
    static member dumps(item: obj): string = nativeOnly
    static member loads(json: string): obj = nativeOnly