Re: [boost] Re: Callbacks Again

From: Jesse Jones (jejones_at_[hidden])
Date: 2000-11-28 21:58:37

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

Wouldn't it be better to have the view make changes by calling directly
into the model? The view has to know about the model to render so you're
not introducing any additional coupling. And the cycle is cut so you don't
have to deal with "life-time tolerance"s.

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

I've been tending to use views that combine View and Controller together
(although I do use classes to handle mouse tracking). A full blown MVC
architecture may make sense if you're designing widgets from scratch, but
it doesn't seem too useful when you're building on top of platform widgets.

  -- Jesse