Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-dev] JSDT InferEngine issues

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. :-)


Inactive hide details for Anselm R Garbe <garbeam@xxxxxxxxx>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>


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



Re: [wtp-dev] JSDT InferEngine issues


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) {

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

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,
wtp-dev mailing list

GIF image

GIF image

GIF image

Back to the top