Community
Participate
Working Groups
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 ------------------------------------------------
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)
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.
