Re: RFC: MI output during program execution

[Daniel Jacobowitz <drow@false.org>]

On Fri, Aug 12, 2005 at 08:13:17PM +0300, Eli Zaretskii wrote:
> I dislike using observers because, in a C program, that looks
> suspiciously like the coder doesn't know what the program is doing.  C
> is not a polymorphic language, so in a C program events happen and
> data of certain type arrives via a 100% predictable and deterministic
> path.  If you know where the event happens which you want to hook,
> simply arrange for your function to be called directly by whatever
> generates or receives that event.

The main reason that I have advocated observers in GDB, in the past, is
for the cases where "we don't know what the program is doing"
- things specific to a target or group of targets or an optional
module, so that we don't have #ifdefs all over the code for targets
which ought to be self-contained.  Also, even in C there can be
multiple places logically generating an "event" - for a perfect
example, look at observer_notify_inferior_created.

I do understand your objections, though I'm not sure what to do about
them.  Personally, I'd love to solve the problem by switching to C++.

In any case, I don't know that the observers implementation, per se, is
a good fit for this particular usage anyway.  MI is not an optional
component, nor would most of the events in question be optional
components; the data flow is simple, just as you described above.
We can just call MI at the right points.  Or add a small level of
abstraction, and call all registered interfaces (TUI, CLI, MI) and see
if any of them need to generate notifications.  That doesn't
change the basic idea of notifying MI at interesting events, which I
think is a nice one.


-- 
Daniel Jacobowitz
CodeSourcery, LLC