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 :-)
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.
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 !!
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 .... :-(
T.
