Review Request 121484: debugger: IBreakpointController refactoring (incompatible API changes)

[Nicolai Hähnle]

> On Dez. 14, 2014, 12:22 nachm., Milian Wolff wrote:
> > good stuff, I guess :) but I wonder about other users of this API, such as the python debugger - do you think they'll continue to work or are there API/behavior changes in here which will require changes to the other debuggers?

Thank you for telling me about kdev-python. I'll look into that one.

This particular changeset is very much binary incompatible, but only trivial source changes (potentially none at all) are necessary to keep other debuggers working. However, as I wrote I do intend to go further in removing the "old style API" in IBreakpointController in later steps of this refactoring. It would be feasible to create a class CompatBreakpointController which would allow old-style debuggers to be ported with relatively few and mechanical source-level changes.

How I will proceed depends a bit on how many more other debuggers are hidden behind the "such as". If it's just kdev-python, I might just evaluate porting that at the same time. If it's more, then I'd be happy to punt that work by introducing such a compat class...


> On Dez. 14, 2014, 12:22 nachm., Milian Wolff wrote:
> > debugger/interfaces/ibreakpointcontroller.cpp, line 208
> > <https://git.reviewboard.kde.org/r/121484/diff/1/?file=333008#file333008line208>
> >
> >     style: * next to typename (you can configure KDevelop to use this style by default, btw.), or just auto. I'd prefer it this way:
> >     
> >         auto model = breakpointModel();
> >         ...

As long as KDevelop's C++ support isn't perfect, I actually prefer explicit types when they're not too cumbersome.

Which configuration do you refer to? I just enter the * and & manually...


> On Dez. 14, 2014, 12:22 nachm., Milian Wolff wrote:
> > debugger/breakpoint/breakpointmodel.cpp, line 52
> > <https://git.reviewboard.kde.org/r/121484/diff/1/?file=333004#file333004line52>
> >
> >     I'd rather this take two arguments, the debug controller and a QObject parent. This is more safe, api-wise (one cannot accidentally breaks stuff by calling setParent), and allows the model to be constructed on the stack, if desired, by setting parent = 0.

Good point about setParent(), I hadn't thought about that. I now go via KDevelop::ICore::self(), because passing a second argument to the constructor seems a bit cumbersome.


- Nicolai


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121484/#review71964
-----------------------------------------------------------


On Dez. 14, 2014, 6:59 nachm., Nicolai Hähnle wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121484/
> -----------------------------------------------------------
> 
> (Updated Dez. 14, 2014, 6:59 nachm.)
> 
> 
> Review request for KDevelop.
> 
> 
> Repository: kdevplatform
> 
> 
> Description
> -------
> 
> Overall, I want to move the code into a shape where BreakpointModel stores all information about breakpoints as presented to the user, and IBreakpointController is a genuine thin interface with no code (or only shim code) in kdevplatform.
> 
> The changes are necessarily binary incompatible, but AFAIU this is okay in current kdevplatform and kdevelop master. There are also minor source incompatible changes; I have already updated kdevelop master so that it is compatible with them.
> 
> The next step after this set of changes will be to change the gdb plugin in kdevelop so that it no longer uses what is now marked as the "old API". This will reduce the interactions between kdevelop and kdevplatform. Once those changes have landed and are stable, the old API in kdevplatform can then be purged.
> 
> Besides the usual reviewing feedback and feedback on the general direction of these changes, I am particularly interested in:
> 
> 1. Are there other users of the debuggers/breakpoint API, and source/binary compatibility policies that I should be aware of?
> 
> 2. I introduced the Column and ColumnFlags enum, where the latter is intended to replace various sets by more compact bit fields. Is there a nice type-safe Qt way of having such a pair of enums, where one is for bitfield corresponding to sets of the other?
> 
> 
> Diffs
> -----
> 
>   debugger/breakpoint/breakpoint.h 23c690f243ec3a46dfb66fd220c620125fd07327 
>   debugger/breakpoint/breakpoint.cpp 7e6de84208050192b6af3242c0cabd5f5515b567 
>   debugger/breakpoint/breakpointdetails.cpp 40d90bc863b10df24adf7189e12265ceb434a690 
>   debugger/breakpoint/breakpointmodel.h 025e78e6d270f870a6ad7d4c526640a3a404f59c 
>   debugger/breakpoint/breakpointmodel.cpp 0810db2f4f844beee13861ce4ba7d91464956fb0 
>   debugger/breakpoint/breakpointwidget.h 66567869e6d1fe8bdb89669c99a8fd1286568630 
>   debugger/breakpoint/breakpointwidget.cpp 48e3a7e6c11f4953098b24121c66a32e934a6acb 
>   debugger/interfaces/ibreakpointcontroller.h 5da4f3efafe7c6e97fbfafe9b639e05d2e0478ea 
>   debugger/interfaces/ibreakpointcontroller.cpp 03a7546166a61a8be9c9b6def2dcb3596c17e82a 
> 
> Diff: https://git.reviewboard.kde.org/r/121484/diff/
> 
> 
> Testing
> -------
> 
> kdevelop gdb unit tests work
> 
> 
> Thanks,
> 
> Nicolai Hähnle
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20141214/8cb44e7c/attachment.html>