Bug 211465

Summary: [api] IProgressMonitor not last parameter
Product: [Tools] Target Management Reporter: Kevin Doyle <kjdoyle>
Component: RSEAssignee: Martin Oberhuber <mober.at+eclipse>
Status: RESOLVED INVALID QA Contact: Martin Oberhuber <mober.at+eclipse>
Severity: minor    
Priority: P3 CC: dmcknigh
Version: 2.0.1Keywords: api
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:

Description Kevin Doyle CLA 2007-11-29 11:40:05 EST 
ISubSystem.connect(IProgressMonitor, boolean) has the progress monitor as the first parameter, but from http://dev.eclipse.org/mhonarc/lists/dsdp-tm-dev/msg01162.html we want progress monitor's to be the last parameter.

-----------Enter bugs above this line-----------
TM 3.0M3 Testing
installation : eclipse-SDK-3.4M3
RSE install  : RSE 3.0M3
java.runtime : Sun 1.5.0_11-b03
os.name:     : Windows XP, Service Pack 2
------------------------------------------------
Comment 1 Kevin Doyle CLA 2007-11-29 11:51:58 EST 
Some additional ones:

RSEFileStoreImpl.getRemoteFileObject(IProgressMonitor, boolean)
Mutex.waitForLock(IProgressMonitor, long)
SftpFileService.progressWorked(IProgressMonitor, int)
SystemTableViewPart.RestoreStateRunnable.runOnceConnected(IProgressMonitor, IMemento, Object, ISubSystem, String, String)
SystemTableViewPart.RestoreStateRunnable.runWithInput(IProgressMonitor, Object, IMemento)
Policy.subMonitorFor(IProgressMonitor, int)
Policy.subMonitorFor(IProgressMonitor, int, int)
Comment 2 Martin Oberhuber CLA 2007-11-29 13:35:10 EST 
In case of 
   ISubSystem#connect(IProgressMonitor, boolean),
it is intentional to have the progress monitor first such that there is always a difference against
   ISubSystem#connect(boolean, IRSECallback)

Imagine a class that happens to implement both IRSECallback and IProgressMonitor. Or, imagine passing in <code>null</code> as IProgressMonitor.
   ISubSystem#connect(boolean, IProgressMonitor)
would make the call ambiguous.

The other examples are mostly not API so we can change them if we want, but I do not see any immediate need to do so. Partially, the main "item of interest" for the methods is the IProgressMonitor (such as in Mutex#waitForLock or SftpFileService#progressWorked), so it is natural to have the IProgressMonitor first.

I do not see sufficient benefit in changing the current method signatures.