Bugzilla – Full Text Bug Listing
| Summary: | DSF API exposing provisional interface | ||
|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | John Cortell <john.cortell> |
| Component: | cdt-debug-dsf | Assignee: | Project Inbox <cdt-debug-dsf-inbox> |
| Status: | NEW --- | QA Contact: | Jonah Graham <jonah> |
| Severity: | normal | ||
| Priority: | P3 | CC: | marc.khouzam, pawel.1.piech, Randy.Rohrbach |
| Version: | 7.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
John Cortell
Pawel, are we going to let Helios ship with this? I don't like the internal API leaks and this is one of them, though it does look like it's been there since DD 1.1. At this stage in the release, I would rather not mess with it. Randy, do you have an opinion? If it's been in there this long, why not just make the interface non-internal/provisional? There's a bit of a tangle of APIs: the flexible hierarchy APIs in Platform Debug are provisional. So as an extension the DSF View Model APIs are provisional as well. But in our APIs, there are a few places where we leak the provisional DSF View Model API by an official API. I'm not really sure what to do about these instances. These complete list of API leaks in DSF is: CSourceLookup.java:66 - CSourceLookup.setSourceLookupDirector(ISourceLookupISourceLookupDMContext, CSourceLookupDirector) has non-API parameter type CSourceLookupDirector DsfCommandRunnable.java:44 - DsfCommandRunnable.getSteppingController() has non-API return type SteppingController DsfSourceDisplayAdapter.java:584 - Constructor for DsfSourceDisplayAdapter with non-API parameter type SteppingController DsfSourceDisplayAdapter.java:108 - DsfSourceDisplayAdapter implements non-API interface ISteppingControlParticipant DsfSourceDisplayAdapter.java:830 - DsfSourceDisplayAdapter.eventDispatched(SteppingControllerSteppingTimedOutEvent) has non-API parameter type SteppingTimedOutEvent ViewerCountingRequestMonitor.java:30 - Constructor for ViewerCountingRequestMonitor with non-API parameter type IViewerUpdate ViewerDataRequestMonitor.java:43 - Constructor for ViewerDataRequestMonitor<V> with non-API parameter type IViewerUpdate ViewerRequestMonitor.java:28 - Constructor for ViewerRequestMonitor with non-API parameter type IViewerUpdate DsfMemoryBlock.java:55 - DsfMemoryBlock implements non-API interface IMemoryBlockUpdatePolicyProvider DsfSourceLookupDirector.java:24 - DsfSourceLookupDirector extends non-API type CSourceLookupDirector Looking at this list again, I think we could address most of these. Although, it'll require a major version change. (In reply to comment #5) > Looking at this list again, I think we could address most of these. Although, > it'll require a major version change. +1. I know I've gone through some difficult hoops to not expose internal APIs. It's disheartening to see violations elsewhere. We should take advantage of the CDT major version change (even if we're predicting another one next year) and clean this up sooner rather than later. (In reply to comment #6) > +1. I know I've gone through some difficult hoops to not expose internal APIs. > It's disheartening to see violations elsewhere. We should take advantage of the > CDT major version change (even if we're predicting another one next year) and > clean this up sooner rather than later. We collectively decided not to change the major version of DSF plugins (they're on 2.1 this year). (In reply to comment #7) > (In reply to comment #6) > > +1. I know I've gone through some difficult hoops to not expose internal APIs. > > It's disheartening to see violations elsewhere. We should take advantage of the > > CDT major version change (even if we're predicting another one next year) and > > clean this up sooner rather than later. > We collectively decided not to change the major version of DSF plugins (they're > on 2.1 this year). I may not be appreciating the importance of leaking APIs, but from a stability point-of-view, I think we should leave the code alone as much as we can at this point. |