Do we need different bindings definitions for each target language?

[alice]

Python, JavaScript etc. have quite different conventions as to how things are named, whether things are properties or getter-methods etc. Do we want to explicitly have API definitions which are specific to each target language?

• Should the cross-platform parts follow the style guides for each target language, e.g. using snake_case for function names in Python and camelCase for function names in JavaScript?
• Should we translate the platform-specific parts into target language style as well?

[alice]

Another example is toString() - Python has a system where you can call __repr__() or __str__() on an object and they'll return different stringified versions of the object for debugging. Javascript, conversely, heavily uses toString() both for debugging and for implicit string conversions (such as JSON.stringify()). Other languages have other types of toString conventions and APIs. It would be nice to support these natively without library users needing to write the same wrapper code each time.

[elima]

(Just my two cents)

Good question. While I see benefits in having an API that feels "native" to the language in question, I would stick to whatever SWIG produces based on our C++ API. And for the C++ API, I would use what makes more sense for C++.

Basically, I wouldn't worry too much about this for now and defer the problem to when we find an issue in one language, or we see that one particular language is important enough as to provide custom API for it (outside what SWIG provides).

[alice]

Yeah I think that's a good strategy for our v0 at least! Focusing on one language at a time will help keep things reasonably scoped, especially when there are so many other variables.

[spectranaut]

Alice brought this up in #105 and it got me thinking about it again, but I just came to Edu's conclusion. I would be a far amount of initial work to write extra interface files, and I want to start actually using the library for testing :)

[spectranaut]

Do we want in the python and node bindings an option to return a JSONifiable object or JSON object that represents the nodes -- with all the properties we can find on that object? We could use getters in javascript (do they have this in python?). This might be slightly more annoying to do in c++.