I’ve already done essentially that for my own sqlite bindings. Sqlite and odin are a natural fit. GitHub - Lord-Hellgrim/sqlite3_bindings
It is a slippery slope.
If Sqlite does get added, which is an OLTP DB, why not add an OLAP DB as well, like DuckDB.
And so on and so forth.
Perhaps, there can be unofficial - official bindings like Clay layout library has: Clay Odin Binding!
Or, we could get comfortable with odin-c-bindgen.
Why not have dear imgui bindings, there are already microui bindings? (edit-correction: microui in vendor is a rewrite, not bindings. This antislip argument is therefore weaker)
Having a database in vendor opens up a lot of casual usage for newcomers to play around with. Most of the vendor libraries are for exactly that. An advanced user will probably want to customize his own bindings, but being able to use sqlite without first figuring out bindgen makes it possible to try odin for all kinds of toy projects that need persistent state.
I would have argued for postgres bindings also, but I think those are not that useful for casual use.
Having a database in vendor opens up a lot of casual usage for newcomers to play around with.
I don’t think this totally works as an argument. Casual users don’t want to futz around with raw C APIs; they want something that is presented in a much more digestible fashion, i.e. a wrapper. Vendor conventionally does minimal wrapping, exposing only the foreign functions and type definitions, and maybe a couple of simple wrapper functions that do basic type conversions.
A casual consumer wants:
- connect
- close
- prepare
- bind
- execute
- execute_once
- some sort of cursor iterator
- (ideally) struct and array unmarshaling
- (maybe, as a subpackage) a query builder
That feature set uses about 20% of the total SQLite C API and probably should be a lot more opinionated than a 1:1 mapping.
Most of the vendor libraries are for exactly that. An advanced user will probably want to customize his own bindings …
I think this conflicts with the intent of vendor. And you bring up a good point about the insane configurability of SQLite- and that point goes against the vendor-in SQLite case. There are something like 100 build options for SQLite, and if the average advanced user is just going to want to customize their bindings anyway (or use some third party library), what’s the point of having it in vendor?
It kinda reminds me of the Java and Javascript world using third party date-and-time libraries because the default Date type is so bad. Or how Python’s built-in http library just sucks, and even requests relies on urllib3 instead of a builtin module.
It’s funny. I wanted SQLite bindings like a week ago, but now after thinking about it harder, I don’t think it’s a good idea. The slippery slope argument applies too, but I think there are other challenges and implications that aren’t immediately apparent.
Here’s the comment by Bill Hall on a reddit post, asking about Dear ImGUI.
So Dear ImGui nor its C bindings are not in
vendorbecause they would be hell to maintain. I understand why people want them, but it’s better to keep them outside ofvendorbecause people will not just want the library but also all of the “example” bindings for different things like SDL/GLFW/etc.This is the same problem the creator of Dear ImGui had originally. Those “backends” were just meant to be examples, but people kept sending in bug reports to make them work for them rather than use them as an example of how to do things.
The other issue is that it’s a massive library. It might sound nice to have but it’s a lot more complex than people realize.
Another reason is that Dear ImGui itself is C++, so you’d have to use the C-bindings for it, and even then you’d have to tweak them to make them be nice in Odin too.
These are good points and I am convinced. A wrapper would be needed and it would need to be quite opinionated.