Bug 195537 - Move ElementComparer From SystemView to Separate File
Summary: Move ElementComparer From SystemView to Separate File
Status: CLOSED FIXED
Alias: None
Product: Target Management
Classification: Tools
Component: RSE (show other bugs)
Version: 2.0   Edit
Hardware: PC Windows XP
: P3 enhancement (vote)
Target Milestone: 2.0.1   Edit
Assignee: David McKnight CLA
QA Contact: Martin Oberhuber CLA
URL:
Whiteboard:
Keywords: contributed
Depends on: 194838
Blocks: 195543
  Show dependency tree
 
Reported: 2007-07-05 11:17 EDT by Kevin Doyle CLA
Modified: 2011-05-25 07:50 EDT (History)
1 user (show)

See Also:


Attachments
Moved ElementComparer to separate file (9.85 KB, patch)
2007-07-09 13:33 EDT, Kevin Doyle CLA
mober.at+eclipse: iplog+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Doyle CLA 2007-07-05 11:17:30 EDT
Currently the ElementComparer class used by the SystemView is inside SystemView, but the SystemScratchpadView also needs to use the ElementComparer.  We should move ElementComparer to a separate file in an internal package for 2.0.1.

-----------Enter bugs above this line-----------
TM 2.0 Testing
installation : eclipse-SDK-3.3
RSE install  : RSE 2.0
java.runtime : Sun 1.5.0_11-b03
os.name:     : Windows XP, Service Pack 2
------------------------------------------------
Comment 1 Martin Oberhuber CLA 2007-07-06 07:44:27 EDT
Could the ElementComparer  also be used for what is requested in bug #194838 ? 
Then it should perhaps be moved to a non-UI package.

Or is the ElementComparer specific to the kind of HashMap being used in the SystemView? Then I'd doubt moving it into a separate class makes any sense.
Comment 2 Kevin Doyle CLA 2007-07-06 10:11:46 EDT
The purpose of the ElementComparer(IElementComparer) is for comparing objects in a jface viewer and getting the hash code for elements.  Since SystemView and SystemScratchpadView can show the same objects we can use the same ElementComparer.  

The only thing is that ElementComparer has to be an IElementComparer as thats what setComparer(IElementComparer) requires for jface viewers.  IElementComparer is in org.eclipse.jface.viewers, so it's a UI thing, but the equals method of the comparer looks like it is the same as what is requested in bug #194838.

The main reason for using the hash map and the ElementComparer, I believe, is because of bug #140941 where duplicate elements can't be found unless they are using an element map.  
Comment 3 Martin Oberhuber CLA 2007-07-06 10:24:20 EDT
Ok, thanks, this makes sense. I think that as soon as bug #194838 is resolved,
the ElementComparer should use the common code for getting the absolute paths.

FYI, the main reason for the elementMap is to improve performance, it's defined
by the parent AbstractViewer class.
Comment 4 Kevin Doyle CLA 2007-07-09 13:33:46 EDT
Created attachment 73352 [details]
Moved ElementComparer to separate file

Moved ElementComparer to a new file and changed it's equal method to call SystemRegistry.isSameObjectByAbsoluteName(a, null, b, null);

Legal Message: I, Kevin Doyle, declare that I developed attached code from
scratch, without referencing any 3rd party materials except material licensed
under the EPL. I am authorized by my employer, IBM Canada Ltd. to make this
contribution under the EPL.
Comment 5 David McKnight CLA 2007-07-09 14:16:53 EDT
I've committed Kevin's patch to cvs.  Thanks Kevin!
Comment 6 Kevin Doyle CLA 2007-07-15 15:27:06 EDT
Verified.