Re: [boost] Re: Callbacks Again

From: Jesse Jones (jejones_at_[hidden])
Date: 2000-12-04 16:32:02

>> This isn't quite enough. On most systems you also need to redraw
>> the view when the OS determines that the window needs to be
>> re-painted. So, I guess you need yet another callback that allows
>> you to fetch the data from the model.
>
>I can understand that in some situations, you have to get access to the
>raw model to repaint the view.  However, in the common case of a
>"traditional" dialog, the underlying GUI toolkit will often take care of
>the necessary caching of content to do repaints.
>
>> In most cases I think decoupling views from the model like this is
>> overkill. However if you do have a use for this decoupling this does
>> seem like a good way to go about it.
>
>So we are reaching a consensus that life-time tolerance and
>multi-casting are very useful properties that are worthwhile to offer in
>a Boost library of signals/any_functions,

Maybe

>even if this does have serious
>ramifications on the design and implementation of the signals.
>
>Whether such consequences are serious enough to warrant two or more
>different kinds of signals, I can not tell.  I just hope that the
>"full-scale" multi-casting and life-time tolerant signals will be
>remembered as a worthwhile target.

What I'd like to see is a simple callback class of the sort we've been
discussing with more sophisticated classes built on top of that. We may or
not provide some of these, but we definitely want to enable them.

>My own experience is that such signals often change much of the design
>of a program, because they allow many things to be implemented in an
>easier way with less coupling, than traditionally.

Even simple callbacks do this. For example, I rarely write custom command
classes anymore. I just reuse a callback_command that takes callbacks for
the do and undo and bind the new and old values to the callbacks. Pretty
slick...

  -- Jesse