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

From: Brian Braatz (brianb_at_[hidden])
Date: 2004-10-25 08:08:25

> -----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.