Mark Miesfeld <[email protected]> wrote: > Here is an outline of the classes: > > * In SQLite, 95% of what any one would use are is done though APIs that > either require a database connection or require a prepared statement. So > the 2 main objects in ooSQLite are: > > Database connection: > >::class 'ooSQLiteDB' public (in SQLite -> struct sqlite3) > >Prepared statement: > >::class 'ooSQLiteStmt' public (in SQLite -> struct sqlite3_stmt)
Something that catches my eye here isn't really a SQLite issue as such, but it seems to me that the implication of SQLite C structs having names which include a "3" is that future versions may be different. Do you have a mechanism in mind to allow future versions of ooSQLLite to use V4/5/6... structs and APIs? How would a programmer dictate which set were to be used for a particular db? Would it not be better to embed a "3" in the name of the class, whatever DLL (or whatever) it uses, and so on? -- Jeremy Nicoll - my opinions are my own ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
