RE: [boost] Re: Library Proposal: database (boost::db)

-----Original Message----- On Behalf Of Jeff Garland Sent: Friday, October 22, 2004 3:35 PM Subject: RE: [boost] Re: Library Proposal: database (boost::db)
On Fri, 22 Oct 2004 15:07:46 -0600, Brian Braatz wrote
Thank you Jeff for setting that up.
I just added
I moved your thoughts to the main page of discussion -- somehow you wound up on a closely related, but not the same name page...
http://www.crystalclearsoftware.com/cgi- bin/boost_wiki/wiki.pl?Relational_Database_Access
[Brian Braatz] Thank You
5) Does not require the usage of RTTI
Why? This seems like an arbitrary restriction to me. Further, for some dynamic query capabilities it seems like it would be a good way to implement
the
needed fuctionality. Of course for simple static SQL it wouldn't be needed.
[Brian Braatz] 2 points- * I blelieve RTTI is a step of last resort (I would be an agreement with Bjarne in the D&E with this principle) * It is possible to make a Boost.Table without having to use RTTI- in fact you can do a better design with out it. I.e. Allowing for the USER of boost.table to plug in their own types (this is important)
6) Allows for the user of the library to "plug in" thier own binding \ subscription system. (to support bound controls) "
Can you clarify what you mean by 'bound controls'?
Jeff
[Brian Braatz] Control binding is one example. And PLEASE understand I am only talking about a boost.table in the CONTEXT of a database framework. (please read the doc referenced earlier). What I am basically saying is that a table needs to support a mixin or something similar to support this usage pattern. To specifically answer your question, this would simply allow the user of the table to "plug in" their own notification system for when data changed. If this functionality were supported, then the user of the class would be able to hook into that allowing for a "update" to an OS specific GUI control. This mechanism however, from a boost perspective, only would need to be allowable in the MODEL of the code created.
participants (1)
-
Brian Braatz