Hi Vadim,
Thank you for reporting it.
I have fixed it in a different way:
- enclosingTypeNames should be null if not specified (it is returned from CharOperation.splitOn())
- bug in TypeInfoFilter constructor
so now it works for me.
Given the following Ruby code:
module Hello
class World
def execute
puts "Hello, world"
end
end
end
I can successfully search for
- hello
- world
- hello::world
Regards,
Alex
----- Original Message -----
From: "Vadim Punski" <vadim.p@xxxxxxxx>
To: "DLTK Developer Discussions" <dltk-dev@xxxxxxxxxxx>
Sent: Sunday, August 9, 2009 7:53:58 PM GMT +06:00 Almaty, Novosibirsk
Subject: [Dltk-dev] TypeSelectionDialog2 in PDT - searching ITypes under namespace.
Hi All,
The implementation of Namespaces in PDT uses IType. There is
a logical reference between IType and it’s Namespace exists, where Namespace is
an enclosing type.
Using the search flow invoked from TypeSelectionDialog2, no ITypes
declared in Namespace returned.
From the code investigation, I’ve found peace of code that
filters the results (see attached).
My question is: Does it makes sense to always perform EXACT
search for enclosing type?
In case it’s not specified, and no enclosing type exists for
particular IType, the flow is OK.
In case where enclosing type exists, but not specified
during the search in a query, it shouldn’t be filtered during the search flow,
isn’t it?
Please see the attached patch.
Regards,
Vadim Punski
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev
