This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: MI output during program execution


> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]