On Wed, Nov 07, 2007 at 06:54:39PM +0100, Tommaso Cucinotta wrote:
> Abdelrazak Younes ha scritto:
>>> Just as an example, now we have a Buffer::changed() method that
>>> uses a WorkArea pointer (wa_) in the Buffer::pimpl object,
>>
>> Not a WorkArea but a WorkAreaManager.
> Yes, infact, I found this comment in WorkAreaManager.h:
>
> "This is a helper class designed to avoid signal/slot connections between a
> |Buffer <cid:part1.02040806.04050400@sssup.it>| and the potentially
> multiple |WorkArea(s)| used to visualize this Buffer
> <cid:part1.02040806.04050400@sssup.it> contents."
>>> in order
>>> to call redrawAll() and trigger a redraw.
>>
>> Compile time and bloat are the two main arguments of Andre' IIRC.
> Ok, I guess there must have been some practical proof making use of
> abnormal Perl scripts generating thousands of signals :-)
Hm? Do we do that?
>> In effect what we have now with the WorkAreaManager is exactly the
>> same at a lesser cost.
> Well, not exactly the same: before there was a signal, where any kind
> of listener with a method with a given prototype could be attached to.
> Now the listeners are forced to be WorkArea instances:
>
> class WorkAreaManager { add(WorkArea *wa); };
>
> This restricts the expected usages of the notification mechanism (i.e.
> now I cannot connect e.g. a BufferView instance to that) -- don't know
> if this is positive or negative w.r.t. the overall design of the
> expected interactions among components.
I'll solve problems when they show up, not theoretically perceived
ones. We did the latter for a decade and it did not really help.
> Furthermore, AFAICR, boost::signal could be associated with a
> boost::connection instance, that had the automagic disconnect capability,
> so that, destroying a WorkArea instance, could lead to the automatic
> destruction of all the connections. Now, the WorkArea destructor must
> remember to call WorkAreaManager.remove(), otherwise SEGFAULT !!
That's one of the benefits of using boost::signal at all: One has to be
_very_ careful about what happens when to connections and their
endpoints, otherwise you get a nice segfault.
> From my standpoint, it's just a matter of adding a method
> (redrawParagraph()) to the WorkAreaManager, as opposed to adding a
> signal to the Buffer interface, i.e. syntactic sugar ....... but I'm
> crying, as I was loving so much that concept of signals and
> connections between the buffer and the view(s) in LyX .... :-(
I have no problems with signals and slot. In fact they'd be my favourite
mechanism as well. However, I do have a problem with boost::signal
(apart from their tendency to crash when used outside a narrow corridor
of use): #include <boost/signal.hpp> pulls in 62000 lines of code.
Just for comparison:
[EMAIL PROTECTED]:/suse/usr/src/lyx/trunk/src > find -name '*.cpp' -o -name
'*.h' -exec cat {} \; | wc -l
45074
Andre'
