Re: [PING^3] [PATCH] Expose signal and syscall catchpoints to Python

[Joel Brobecker <brobecker@adacore.com>]

> 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