Bug 107656 - [Viewers] DeferredTreeContentManager has API methods that take internal parameters
Summary: [Viewers] DeferredTreeContentManager has API methods that take internal param...
Status: VERIFIED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.0.2   Edit
Hardware: All All
: P2 normal (vote)
Target Milestone: 3.2 M5   Edit
Assignee: Boris Bokowski CLA
QA Contact:
URL:
Whiteboard:
Keywords: api
: 111028 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-08-22 14:55 EDT by Curtis d'Entremont CLA
Modified: 2006-02-14 16:09 EST (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Curtis d'Entremont CLA 2005-08-22 14:55:11 EDT
In the class DeferredTreeContentManager (public API), there are some protected
methods, which in turn are also API (it doesn't say anywhere not to override
these), however, some of these methods, like startFetchingDeferredChildren, take
non-API classes as parameters. Namely, PendingUpdateAdapter.

I don't think it's correct to have an API method that takes non-API parameters.
You could change the class name of that internal class and break anyone who
overrides this method.

I suggest deprecating the current methods that take this internal parameter and
adding a new method for each of them that takes a more general, API parameter
such as IAdaptable or IWorkbenchAdapter. That way you can hide the
implementation of the actual item behind that interface, without breaking anyone
currently using the one with internal parameters.
Comment 1 Boris Bokowski CLA 2005-09-29 08:29:38 EDT
*** Bug 111028 has been marked as a duplicate of this bug. ***
Comment 2 Boris Bokowski CLA 2005-09-29 08:36:38 EDT
Jim, what is the policy for cases like this? The original suggestion makes sense
to me, or is there something else I could do? I guess just removing the method
is not an option, but what about widening the parameter type?
Comment 3 C. Lamont Gilbert CLA 2005-09-29 12:39:08 EDT
The simple solution would be to move PendingUpdateAdapter out of internal. 
AFAICT, there is no need for it to stay.

Personally all I want is to change the name displayed while the children are
being fetched.  A simple method on the ContentManager would work better for me.
 Or I suppose I could write my own.  so I think as stated its on the
architecture to send a clear message.
Comment 4 Boris Bokowski CLA 2006-02-13 19:02:55 EST
Made PendingUpdateAdapter API. This is a potential breaking change for subclasses of DeferredTreeContentManager. However, since there was no way for subclasses to override these methods, or to call them with anything other than null (which is not permitted), I believe this is still an OK change.

Released >20060213.
Comment 5 Boris Bokowski CLA 2006-02-14 14:54:46 EST
Introduced a factory method in DeferredTreeContentProvider, made the constructor of PendingUpdateAdapter public, and added @since 3.2 tags.

Released for I20060214-1600.
Comment 6 Boris Bokowski CLA 2006-02-14 16:09:14 EST
[I20060214-0800]

Verfied on Windows XP.