Summary: | [search] Unable to search just for references to overridden method | ||||||
---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Randy Hudson <hudsonr> | ||||
Component: | Core | Assignee: | Frederic Fusier <frederic_fusier> | ||||
Status: | VERIFIED FIXED | QA Contact: | |||||
Severity: | enhancement | ||||||
Priority: | P3 | CC: | daniel_megert, dberindei, ec23, koen.van.dijken, markus.kell.r, martinae, max.gilead, neil, petavy, philipp.hofmann, shortcutter | ||||
Version: | 3.0 | Keywords: | api | ||||
Target Milestone: | 3.3 M2 | ||||||
Hardware: | PC | ||||||
OS: | Windows XP | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
Randy Hudson
2004-09-07 15:50:55 EDT
We do a polymorphic search since there could be variables of type Rectangle actually valued to instances of Obstacles, e.g.: Rectangle r = new Obstacles(...); r.containsPoint(...) However, this should not result in looking for senders of Rectangle.containsPoint, as it should eliminate matches to other subtypes of Rectangle (i.e. not in the branch of Obstacles). Ok to close? I don't want to close because I am unable to do what I need. What is the generated bytecode for: Obstacle o = new Obstacle(x, y, w, h); o.containsPoint(point); ?? Is it a call to Obstacle#containsPoint(), or Rectangle#containsPoint(..)? I want to search for all places where the compiled bytecode refers to Obstacle#containsPoint(..), and this isn't possible. The polymorphism makes sense usually, but in my specific case Obstacle is never cast to or referred to as a Rectangle. It is simply for convenience that it inherits some of the utility method on Rectangle. BTW, is there a way to search for casting of a type to its supertype?? I agree this polymorphic search is sometimes annoying when you're sure that you do not want it! I guess we can think about a new option in search to activate it or not, I'll put this in my list... About search for a cast, it's not possible for now, but bug 73205 addresses this request. Unfortunately, I'll not have enough time to add this option... Defer post 3.1 Reopen for 3.2 *** Bug 85347 has been marked as a duplicate of this bug. *** *** Bug 105768 has been marked as a duplicate of this bug. *** The polymorphic search is very annoying when searching with wildcards. For instance searching for references to SomeClass.get* will find all the references to Object.getClass() - when all I want is references to the getters defined in SomeClass. Is there any change it'll get fixed soon? It's so very problematic when I want to find references or declarations of a method which I know should be found in three or four places in a project but instead get hundreds of hits from packages like com.ibm.icu or com.sun.corba and all irrelevant places from all over the project. :/ *** Bug 116208 has been marked as a duplicate of this bug. *** *** Bug 121016 has been marked as a duplicate of this bug. *** *** Bug 108219 has been marked as a duplicate of this bug. *** Unfortunately, this new option was missed for 3.2 and needs to be deferred again. I've tagged it 3.3 + [API] to avoid doing this error twice. Sorry for the delay... Reopen as the pressure get more and more important on this problem (see bug 156941 comment 2)... I'd rather prefer a new flavor on SearchMatch to allow user to filter polymorphic matches than a specific pattern. Having a specific pattern would not save too much time as the filter could only be applied while resolving possible matches (ie. just before creating SearchMatch to report it). A flag on SearchMatch sounds good. JDT/UI can then easily add a filter for polymorphic matches to the search result view. BWT: comment 14 meant bug 156491. Will the 'polymorphic' flag be set for matches deeper down in the hierarchy as well? I.e. if I expand comment 0 and add a class MyObstacles that extends Obstacles and overrides containsPoint(int, int) again, will calls to myObstacle.containsPoint(..) be considered polymorphic or not? Or do we even need 2 flags here? (In reply to comment #16) > A flag on SearchMatch sounds good. JDT/UI can then easily add a filter for > polymorphic matches to the search result view. BWT: comment 14 meant bug > 156491. Ooops, thanks > > Will the 'polymorphic' flag be set for matches deeper down in the hierarchy as > well? I.e. if I expand comment 0 and add a class MyObstacles that extends > Obstacles and overrides containsPoint(int, int) again, will calls to > myObstacle.containsPoint(..) be considered polymorphic or not? Or do we even > need 2 flags here? > In patch I provided in bug 156491 comment 9, these kind of matches are not flagged as polymorphic. However, it's not a big deal to do it. The only remaining questions are: is it really necessary and f so, is it important to distinguish if the polymorphism comes from superclasses or subclasses...??? I can't see any use cases where it could be necessary but I'm sure you have something in mind, haven't you? Created attachment 50171 [details] Proposed patch This patch include also fix for bug 156491. Note that JDT/UI needs to implements corresponding filter in Search View to have this issue completely fixed... JDT/Core patch released for 3.3 M2 in HEAD stream. Wait for JDT/UI input to set this bug as fixed... I've released a filter for polymorphic matches to the Java search result page. The filter is enabled automatically in new workspace. Re comment 17: Methods declared in subtypes as well as methods declared in supertypes are polymorphic matches now. Just 1 flag for all. Verified for 3.3 M2 using build I20060918-0010. >The filter is enabled automatically in new workspace. This is is no longer true. See bug 157814 for details. *** Bug 116295 has been marked as a duplicate of this bug. *** |