Kristian Nielsen wrote: > Jay Pipes <[EMAIL PROTECTED]> writes: > >> Mats Kindahl wrote: > >>> I this we should seriously consider a robust interface into the internals of the >>> server. For this purpose, the THD/Session should be an opaque pointer, and then >>> be should provide a set of functions to get information from the opaque pointer. >> +++ I've been arguing for this approach for a while. Zero access to >> internals except through a well-defined and documented interface (i.e. >> public methods of a class). Want to change a session variable, then >> change it via an API...not via access to a public member variable. > > I think we also need to be aware of performance. > > Eg. for storage engine plugins, I think inlined access to internals (item, > condition pushdown, ...) is necessary for best performance. For storage > engines, I think performance is more important than ABI stability. > > For other engines, performance may not be a problem, so they could use only > opaque interfaces. > > So maybe some interfaces can be opaque, and some should remain internal?
I respectfully disagree. :) Cores are plentiful, disk is plentiful, memory is plentiful. What isn't? Developers and DBAs. So, given a choice of clean, stable, and standardized interfaces vs. developers hacking on internals (and having to understand the mess), I prefer stable public interfaces via an object. Furthermore, there is nothing preventing inlining of public interface methods on a class object. Given this, I fail to see where performance regression would be significant. I'd prefer to let compiler developers handle performance issues of this nature. Optimizing for this kind of thing gets us into a situation like, well, like what we have today. -j _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
