Re: [wtp-dev] JSDT InferEngine issues
2009/6/30 Christopher Jaun <cmjaun@xxxxxxxxxx>:
> If you want to request that the currentContext object be made public please
> open a bugzilla enhancement against the JSDT component. We may be able to do
> that in WTP 3.2.
> However, some extensions of the inference engine don't need to work with the
> currentContext object directly, so you may be able to find a way to work
> around this problem.
Yes I think just having access to currentContext won't help. I think a
slight re-design of the current InferEngine might be of some help -- I
could provide a patch with more detailed proposals later.
So far the inferrenceSupport extension point looks rather pointless to
me if it requires a complete new ASTVisitor implementation or enables
me just to overload some visitors of the default InferEngine which
aren't of real use imho.
> I'm a little unclear of what your end goal is. If you have a library of pure
> extend the inference engine to handle specific language constructs that
> handle Dojo declare or provide statements, so that they editor knows to
> treat Dojo classes as types.
My use case is to enrich the InferEngine with JS APIs that haven't
been specified and aren't written in JS, because they are usually
implemented natively (similiar to the geolocation API for
instance). However I have WebIDL specs for all of them, so all I want
to achieve is enriching the InferEngine with that information from the
One possible solution is tranforming the WebIDLs into JS library
stubs, though my favourite solution would really be to enrich the AST
with some global members accordingly.
Perhaps I'm just blind and miss some other extension point which could
be used for that. I also gave the javaCompletionProposalComputer
extension point a try, but its implementation seems to rely on AST
nodes, so if something isn't in the AST it can't be completed was my
conclusion and I thought the right extension point must be