Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 43210

Summary:	SearchSearchEngine.searchDeclarationsOfSentMessages doesn't return constructors
Product:	[Eclipse Project] JDT	Reporter:	Olivier Thomann <Olivier_Thomann>
Component:	Core	Assignee:	JDT-Core-Inbox <jdt-core-inbox>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	dirk_baeumer, markus.kell.r, mljrg, wege
Version:	3.0
Target Milestone:	---
Hardware:	PC
OS:	Windows 2000
Whiteboard:

Description Olivier Thomann

2003-09-17 07:53:30 EDT

From EC,
 SearchEngine>>searchDeclarationsOfSentMessages(ws, someType, collector)

 to find all declarations of methods that were called from 'someType', I
 don't get any constructor.

 1) Do I do anything wrong?
 2) Is there a good reason for omiting the constructors?
 3) Does a feature request to return the constructors make sense?

This looks like a bug.

Could you please specify what build you are using.

Comment 1 Chris Wege

2003-09-17 10:45:47 EDT

I tested with

Version: 2.1.1
Build id: 200306271545

Comment 2 Kent Johnson

2003-09-24 15:17:20 EDT

Actually the spec for the method says it answers message sends, not constructor 
invocations. So its not a bug & we won't change the given method.

Is there a need to find the constructor invocations?


The example shows that constructors are not answered:

"Consider the following code:
class A {
	void foo() {};
	void bar() {};
}
class B extends A {
	void foo() {};
}
class X {
	void test() {
		A a = new B();
		a.foo();
		B b = (B)a;
		b.bar();
	};
}
then searching for declarations of sent messages in method X.test() would 
collect the methods A.foo(), B.foo(), and A.bar()."

Comment 3 Chris Wege

2003-09-24 16:53:48 EDT

There is a need to get the constructors for me. I am using Eclipse as a research
platform (I am not the only one) where I not only want to see the method
invocations but also the constructor invocations. I see no other way to get the
constructor invocations than by parsing the method code for the moment.

Consistency of the API is another reason. Eclipse represents constructors as
IMethod's that return true for isConstructor(). Thus I was assuming that the 
search engine would return all IMethod's that were invoked - including constructors.

Currently, only the refactoring tooling uses the search engine method. So now
would be the perfect time to change something here. The refactoring tooling
post-processes the search results in a filter anyhow.

Comment 4 Dirk Baeumer

2003-09-29 17:14:27 EDT

To not break the existing API we could do the same trick Philippe suggested 
for the "search for constructors". We could extend the limitTo flag to give 
more control over the expected result set.

Comment 5 Chris Wege

2003-10-13 07:31:37 EDT

For now I can use the model of the new CallHierarchy view to find all method
calls including constructor invocations of explicit constructors. But maybe in
some point in time the CallHierarchy plug-in wants to use the SearchEngine
instead of using its own AST visitor.

Comment 6 Philipe Mulet

2004-03-25 06:41:00 EST

Will reconsider post 3.0

Comment 7 Denis Roy

2009-08-30 02:19:31 EDT

As of now 'LATER' and 'REMIND' resolutions are no longer supported.
Please reopen this bug if it is still valid for you.

Comment 8 Mário Guimarães

2011-07-28 06:47:32 EDT

Can you reopen this bug? 
Having constructor information through searchDeclarationsOfSentMessages method makes sense, would be a cleaner and safer way than that of Chris, and it would be usable.
Thanks