Feature Discussion: Bindings for other languages

[Caleb-T-Owens]

Feature Discussion: Bindings for other languages

• Time frame to consider working on: After API stabilization

Story Time

So, I was two hours into compiling gcc and was reading some of the things that it was compiling and one of the things was this gccgo part which is the gcc go language compiler, and I started doing some reading on this, and one of the things that it talked about was the generation of go bindings for a c++ library and this really intrigued me. Turns out that gccgo is supposed to be bad at generating bindings, but there is another kit called cgo that can be used to make bindings.

Now to the topic

Would it be good to make our own bindings?

Why would this be the case? Surely if someone wanted bindings in their language they could just make them themselves. That is what has happened with libraries like GTK and SDL. I however think that by making our own bindings in languages we could go a step further and also implement a mild layer of abstraction that makes sense for each language that we make bindings for which could end up being significantly better to use than a more simple direct one to one system of bindings.

What languages would be good to make bindings or a wrapper for?

I think this is a discussion that will have near the same level of heat as "what is the best language to use for X" and with a thousand correct answers it would be a hard one to pick but I think that the following two would be a good couple to consider first.

• Python. Python is a very popular language with many new programmers and with a lack of good GUI libraries could be well accepted by the community.
• Rust. Rust is a new language that is trying to be the new systems/do it all programming language however it lacks many GUI libraries with just some basic QT and GTK bindings.

[takev]

We should have language bindings. What happens often with Python is that there are low-level bindings which are often generated. And then there is a high level binding written in Python that makes the binding more "pythonic".

Probably the biggest stumble-block for the developing binding is all the template-code. Although that may be an asset as well, since we could directly instantiate around the language API's types.

[Caleb-T-Owens]

So with the type params, in JS it's quite common for there to be these builder classes where there are a set of methods on a object that mutate it (or more often to add to a list of instructions for something that is going to be lazily evaluated) and return a reference to it so you can chain a bunch of these to form a complex instruction which then gets completed with some build() method that executes the whole thing. An example being ```js const subquery = await knex('users').where('votes', '>', 100).andWhere('status', 'active').orWhere('name', 'John').select('id').query(); ``` Where `knex('users')` is the constructor and the rest of the mythods build onto it and `.query()` executes the query. And my thinking was that a similar system could be used to build the components.

…

On Thu, 4 Mar 2021 at 22:35, Take Vos ***@***.***> wrote: We should have language bindings. What happens often with Python is that there are low-level bindings which are often generated. And then there is a high level binding written in Python that makes the binding more "pythonic". Probably the biggest stumble-block for the developing binding is all the template-code. Although that may be an asset as well, since we could directly instantiate around the language API's types. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#63 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADF4JK4LXCWD5XRWVDJINM3TCADKLANCNFSM4YUBV5QA> .