On 8 Jan 2016, at 12:22am, Jim Callahan <jim.callahan.orlando at gmail.com> wrote:
> The existing SQLite APIs are correct, but hard to use in the > sense that creating an interface from an OOIL language is more involved > than just "wrapping" one by one a set of functions. What I am proposing is > a second set of APIs that when trivially wrapped for use in an OOIL > language would result in a function that makes sense to an OOIL programmer You may be interested to know that the SQLite3 interface to PHP is object oriented. Connections and prepared statements are objects. Most things you can do with them are methods of those objects. Because every language implements objects its own way, having a low-level object-oriented API for SQLite wouldn't help anyone trying to write an OO interface for their language. It would actually be harder for them to handle both an SQLite3 object and their own kind of object and 'translate' between their needs. Error-handling, for instance, would be a nightmare since you'd have to keep an errored-out SQLite object around and never quite know if you could dispose of it yet. I think things work fine as they are. Simon.
