Re: [wtp-dev] JSDT InferEngine issues

[Christopher Jaun <cmjaun@xxxxxxxxxx>]

HI Anselm,

You are correct in stating that we do not have a good way to infer the type of parameter 'x' in a statement such as...

serach.find(a, function(x) {x....});

I did find that if I do something like this....

serach.find(a, /** @param {Date} x */ function(x) {x....})

.... it does correctly infer that x is a type Date. Though we would not expect an end user to be writing code with JSdoc nested in it like in the above example, so its not really a solution for your scenario.

This does sound like a case where we would want metadata in a library to specify that a function takes a function as a parameter(which we can do now) and also specify the parameter values of that function, which I don't believe is possible right now.

Unless I'm missing something this does not sound like a case where you'd need to create a custom extension to the inference engine. My understanding is that your library is just plain _javascript_. Is that correct? If additional work is needed to infer the parameters types of a parameter function that sounds like an enhancement for the default _javascript_ inference engine.

We would welcome any contributions you may be able to provide in this area. Sounds like your already have a good understanding of the inference engine. :-)

Thanks,
Chris


Anselm R Garbe <garbeam@xxxxxxxxx>

Anselm R Garbe <garbeam@xxxxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx

07/01/2009 11:11 AM

Please respond to
"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>

To	"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>
cc
Subject	Re: [wtp-dev] JSDT InferEngine issues

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
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev