Re: [boost] Re: Callbacks Again

From: Asger Alstrup Nielsen (alstrup_at_[hidden])
Date: 2000-11-21 03:34:06

> I dunno. I've done quite a bit of GUI programmin with "dumb" 
> callbacks and I've never needed a callback that got updated when 
> the target went away. I think the stuff you've been talking about 
> is well worth considering, but IMO it should be built upon a 
> simple, general, non-invasive callback class.

One example where it is a God-send to have life-time tolerance is a
classical model/view architecture:

You have a Table class which represents a table in a database. This
class can emit a signal when data in the table changes.
You have a View class. This class can emit a signal when it changes data
in the view.

Now, you have a controller object which sets things up like this:

The View class will connect to the signal from the Table class, such
that the View can be updated when the database changes (by some other
source).
The Database class will be set up to listen to the signal from the View
class, such that the database will be updated when the user changes some
data in the view.

So the setup can graphically be represented like this:

+------------------------+             +---------------------+
| Table                  |             | View                |
+------------------------+             +---------------------+
| Signal tableChanged    o------------>o Slot tableChange    |
|                        |             |                     |
| Slot update(new record)o<------------o Signal updateRecord |
+------------------------+             +---------------------+

Since the connections form a loop, lifetime tolerance simplifies things
a lot.

This architechture is a good architechture. The Table and View classes
are independent. You can rig up things in many interesting ways:

Suppose you want several views of the same table. This is solved by
instantiating several Views, and setting up connections for each.
If you want several tables to replicate the same data, you can do this
by instantiating several Tables and setting up the connections.

Also consider how to handle the situation where tables and views come
and go in arbitrary ways. 

You can argue that you can use a controller object to handle all of this
in a better way. But then you have to require that the controller object
has a lifetime that is longer than all of the Tables and Views, and you
have to use the double number of connections, and a dispatcher
mechanism. I find that this is not as flexible.

I prefer that a controller has the job of setting up the connections
directly between the actors, rather than owning the double number of
connections, handling this connections, and taking care to life longer
than the rest.

Greets,

Asger Alstrup Nielsen