From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17226 invoked by alias); 12 Feb 2005 15:52:42 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 17191 invoked from network); 12 Feb 2005 15:52:36 -0000 Received: from unknown (HELO romy.inter.net.il) (192.114.186.66) by sourceware.org with SMTP; 12 Feb 2005 15:52:36 -0000 Received: from zaretski (pns03-205-52.inter.net.il [80.230.205.52]) by romy.inter.net.il (MOS 3.5.6-GR) with ESMTP id ANI01114 (AUTH halo1); Sat, 12 Feb 2005 17:51:48 +0200 (IST) Date: Sat, 12 Feb 2005 21:50:00 -0000 From: "Eli Zaretskii" To: Daniel Jacobowitz Message-ID: <01c5111a$Blat.v2.4$461db0e0@zahav.net.il> Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=ISO-8859-1 CC: jjohnstn@redhat.com, gdb-patches@sources.redhat.com In-reply-to: <20050211171751.GA31423@nevyn.them.org> (message from Daniel Jacobowitz on Fri, 11 Feb 2005 12:17:51 -0500) Subject: Re: [RFA]: Modified Watchthreads Patch Reply-to: Eli Zaretskii References: <20041210230603.GA23419@nevyn.them.org> <01c4df10$Blat.v2.2.2$6f63d1a0@zahav.net.il> <20041210233700.GA24439@nevyn.them.org> <01c4df73$Blat.v2.2.2$5e13b740@zahav.net.il> <20041211161136.GA13865@nevyn.them.org> <01c4dfa2$Blat.v2.2.2$486cc380@zahav.net.il> <20041211173256.GA15506@nevyn.them.org> <41E6CA85.5090407@redhat.com> <20050210195838.GA12332@nevyn.them.org> <01c5105b$Blat.v2.4$bb9e28a0@zahav.net.il> <20050211171751.GA31423@nevyn.them.org> X-SW-Source: 2005-02/txt/msg00122.txt.bz2 > Date: Fri, 11 Feb 2005 12:17:51 -0500 > From: Daniel Jacobowitz > Cc: jjohnstn@redhat.com, gdb-patches@sources.redhat.com > > My current feeling is that either: > (A) we should use the same mechanism to create two sets of hooks, > one to be considered a general extension mechanism and the other > an internal modularity aid; > or > (B) we should define the observers as the latter rather than the > former, and declare the former niche unfilled. > > Otherwise there's just a lot of wasted code duplication. > > What do you think? Am I way off on the role of observers? Since we > don't "support" plugging arbitrary code into them, I have trouble > considering them an extension mechanism. I initially thought that observers were introduced as an extension mechanism. But it begins to look like they are intended to be used as in the C++ observer paradigm. I don't like that, since GDB is not a C++ program, and because using observers in GDB obfuscates the flow of control and data and makes the GDB code harder to understand. But it looks like mine is the minority opinion, judging by past discussions of this.