From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112623 invoked by alias); 19 Dec 2015 03:56:58 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 112595 invoked by uid 89); 19 Dec 2015 03:56:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=H*Ad:D*me, prep, Hx-languages-length:1695, H*i:sk:001a113 X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Sat, 19 Dec 2015 03:56:53 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 5177B1164DE; Fri, 18 Dec 2015 22:56:51 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id flDfHTp50wGh; Fri, 18 Dec 2015 22:56:51 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id E7FD31164DD; Fri, 18 Dec 2015 22:56:50 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 0A7C6406CD; Sat, 19 Dec 2015 07:56:47 +0400 (RET) Date: Sat, 19 Dec 2015 03:56:00 -0000 From: Joel Brobecker To: Doug Evans Cc: Alessandro Di Federico , gdb-patches@sourceware.org Subject: Re: [PING^3] [PATCH] Expose signal and syscall catchpoints to Python Message-ID: <20151219035647.GH29928@adacore.com> References: <001a1136affa52fa4b052730e695@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001a1136affa52fa4b052730e695@google.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-12/txt/msg00395.txt.bz2 > This will need doc additions too of course, but before you > spend time on that there is a high level issue that we > (the community) should decide on: > Is it time to start subclassing breakpoints instead of > continually extending the one uber-breakpoint class? > IOW, should catchpoints be a subclass of breakpoints? > > Subclassing is clearly a better way to go, > so I'm kinda thinking now's the time. Thinking out loud... I like the idea of starting subclassing. And this is potentially a direction we could be going too in the long term with the core part of GDB after the move to C++ for instance (not sure it makes sense, just thinking aloud). Doing it with the C++ interface could also be good prep for thinking about what would work and what would not. The question then becomes backward compatibility. I think it can fairly easily be preserved, by keeping the Breakpoint class as is, with both breakpoint and whatever catchpoint support it already has as is, and only adding the new capabilities in a the new child class? FTAOD, the child class would have all features of catchpoints through the Breakpoint class, combined with whatever new feature we implement over time. This would give people some time to transition from the current approach to the new one, before we decide to remove the catchpoint stuff from the Breakpoint class. At some point, we might find that we want class Breakpoint to be a child of some RootBreakpoint or AbstractBreakpoint class. That should be easy to do. The part that might not be so easy is getting rid of the "type" argument in Breakpoint.__init__'s method... -- Joel