Re: [wtp-dev] JSDT InferEngine issues

[Anselm R Garbe <garbeam@xxxxxxxxx>]

Hi,


as a follow up to the earlier discussion I have some other questions,
which also provide more detail about what I'm trying to achieve with
the InferEngine and the APIs I'm going to expose.

Imagine the following API specified in WebIDL:

module search {

  interface SearchResult {
    attribute long size;
    DOMString elementAt(in long i);
  };

  [Callback] interface SearchSuccessCallback {
     void onSuccess(in ResultArray result);
  };

  [Callback] interface SearchErrorCallback {
    void onError(in Error error);
  };

  [NoInterfaceObject] interface SearchEngine {
    void find(in DOMString pattern, in SearchSuccessCallback sc, in
SearchErrorCallback ec);
  };

};


When editing some JavaScript code with an imagined JSDoc'ed JS library
out of this WebIDL, there'll be a global member with the name "search"
that itself will expose a method "find". So when typing

  search.findCtrl+Space the editor will correctly expand to something like

  search.find(x, y, z)

however what I intend to achieve is the following:

  search.find("foo", function(x) {
           x.Ctrl+Space

and here I'd like to see that x actually exposes the attribute "size"
and the method "elementAt". If the [Callback] attribute on the WebIDL
interface wouldn't be there, similiarly I want to achieve that

  search.find("foo", { onSuccess: function(x) {x.Ctrl+Space

exposes "size" and "elementAt" as well.


The problem I'm facing is, that as far as I understand the AST model
and JSDoc syntax processing supported so far, there is no abstraction
for a function type argument yet that itself refers to a specific
InferredType that provides the glue to the SearchResult interface in
the given example.

This lack in the JSDoc parsing made me think perhaps I can achieve
that with sub-classing the InferEngine natively. Though, when looking
at how InferredType is designed atm, I think it won't be possible,
because first of all InferEngine.FunctionType is fixed (I can't
manipulate InferredType.superClass member on a case by case basis and
secondly that won't be sufficient at all, because I'd need to have a
InferredType.parent member that references to the exemplified
SearchResult InferredType instead. Or am I missing something?

So assumed I'd have extended the InferEngine mechanism to provide such
extended inference as I'm looking for (of course I'll contribute that
portions of code back to you), the main question for me that would
remain is, what's your preference on the library input side?

I can see two options:

a) Keep the JSDoc parsing as is and only provide the extended
inference support for implementations that use the inferrenceSupport
extension point and feed the extended inference info natively into the
AST

b) Extend the JSDoc parsing with more metadata (not sure about the
details yet), in order to provide the extended inference support just
on top of the existing mechanism

I think you'd prefer b) pretty much. For me this is an important
decision, because it'll effect how such extended inference support is
implemented. If you agrre that b) would be the right way to go, there
might be no reason for me at all to implement my sub-classed
InferEngine at all, but just to contribute the extended changes to the
existing implementation back to you, in the hope you will accept that
;)

Or my ideal case would be, someone else is already working on this ;)

What's your view on this?

Kind regards,
Anselm