Re: RFC: MI output during program execution

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> Date: Fri, 12 Aug 2005 16:30:52 -0400
> From: Bob Rossi <bob@brasko.net>
> 
> On Fri, Aug 12, 2005 at 08:13:17PM +0300, Eli Zaretskii wrote:
> > > Date: Fri, 12 Aug 2005 07:49:29 -0400
> > > From: Bob Rossi <bob@brasko.net>
> > > Cc: gdb-patches@sources.redhat.com
> > > 
> > > On Fri, Aug 12, 2005 at 12:43:19PM +0300, Eli Zaretskii wrote:
> > > > > Date: Thu, 11 Aug 2005 21:28:10 -0400
> > > > > From: Bob Rossi <bob@brasko.net>
> > > > > Cc: Eli Zaretskii <eliz@gnu.org>, gdb-patches@sources.redhat.com
> > > > > 
> > > > > Thanks for all the guidence so far. Even though you have not attempted
> > > > > the observer approach, how do you feel about it? Is this something that
> > > > > you think could be accomplished with the current FSF GDB? Nick, Daniel
> > > > > and Eli, do you like this approach?
> > > > 
> > > > The record will show that I dislike using observers in core GDB
> > > > sources (i.e. in the sources released with official GDB
> > > > distributions).  But my opinions on this are usually voted down.
> > > 
> > > I would like to become more educated on the pros/cons of the two possible
> > > approaches in solving this problem. What do you not like about the
> > > observer approach that the hook approach solves better?
> > 
> > I'm not sure what you mean by ``the hook approach''.  From my point of
> > view, observers are simply one implementation of the hook approach.
> 
> Yes, as I was thinking about this later, I realized that this was true.
> However, I was thinking the the "hook approach=>jim's implementation",
> was simply an implementation of the observer design pattern. The
> observer pattern can be defined as,
> 
>    Define a one-to-many relationship between objects so that when one
>    object changes state, all its dependents are notified and updated
>    automatically.
> 
> Obviously, there is a 1-1 relationship between the FE and GDB, but I
> don't think that should be a big deal.

It is a big deal.  Problems with an essential one-to-one relationship
don't need the complication of an implementation designed for
one-to-many relations.  There the observer pattern doesn't make any
sense.  On the other hand, if a relationship is one-to-many but just
happens to be one-to-one because there is only one of many finished
implementations, the observer pattern makes sense.

> > 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.
> 
> OK, this seems reasonable. One thing to note is that the FE may be in C++
> or Java, which would lend nicely to the Observer design pattern. CGDB is
> written in C, so this doesn't really matter to me.

Oh come on.  A lot of those "modern" languages are just syntactic
sugar (and in the case of C++ its a full wedding cake that makes you
sick if you eat too much of it).  C programmers have been using the
observer pattern for ages, even before the name observer pattern even
existed.

> > In addition, using observers raises an issue with multiple observers
> > watching the same events and stepping on each other's feet.  In other
> > words, the observer facility doesn't promise anything about the order
> > in which the observers are invoked, and doesn't give us control on the
> > order, so a potential arises for conflicts, if several observers futz
> > with the same data structures or try to produce opposite effects.
>

This is the real reason to be careful with the observer pattern.  If
you encounter interdependencies between observers, the observer
pattern is not the right solution for your problem.

Mark