Issues with typed properties and homogeneous arrays

[apr...@tibco.com]

Good day tern-dev,

I have a large *.js library that was generated from XSDs. I'm trying to support doc generation by JSDoc3 and content assist, doc hovers and validation in Eclipse using Tern.java (having all but given up on flakey JSDT). I rely on doc_comment: {"strong" : true} to derive type information from JSDoc annotations on properties defined in prototypes (as all prototype properties are explicitly initialised to the value undefined).

I've noticed the following issues:

1. Many properties are uni-valued references to instances of other types defined in the library. They are JSDoc-annotated with @type {Class}. PROBLEM: let instanceVar = new Class(); content assist for instanceVar.propertyName. shows proposals from the Class constructor function object, not the instance properties defined in the constructor or its prototype.
2. Other properties are multi-valued references to instances of other types defined in the library. They are implemented as homogenous arrays and I've tried JSDoc-annotating these properties variously with JSDoc3-style @type {Class[]} and @type {Array.<Class>} and the Tern-only (non-JSDoc-compliant) notation @type {[Class]}. PROBLEM: let arrayPropertyName be the name of such an array property; using the {Class[]} style Tern produces no content assist at all for instanceVar.arrayPropertyName. For the other two styles proposals correctly include members of Array and Object. However, proposals for instanceVar.arrayPropertyName[index]. show shows proposals from the Class constructor function object, not the instance properties defined in the constructor or its prototype.

As an experiment I tried removing the @type annotations and respectively initialising the uni- and multi-valued properties to a new instance or array literal containing a new instance. In this case, content assist works, and both instanceVar.arrayPropertyName. and instanceVar.arrayPropertyName[index]. produced the correct proposals (i.e., Array and Class instance members respectively). Significantly, content assist does work for uni- and multi-valued properties with built-in element types such as Date, even if the type information is provided by @type {Date} and @type {Array.<Date>} tags.

In summary, member type information contributed by an @type JSDoc annotation that references a local type is not correctly interpreted by Tern. The same effect is also observed if the file is condensed and loaded by a Tern plug-in.

The attached tern-issues.js file illustrates the above cases.

Thanks for your thoughts,

--A

[apr...@tibco.com]

Hmm, resounding silence... I think this is a rather significant bug but was hoping for some feedback before I report it.

To summarise: member type information contributed by an @type JSDoc annotation that references a local type is not correctly interpreted by Tern. The same effect is also observed if the file is condensed and loaded by a Tern plug-in.

[Marijn Haverbeke]

If I load your file into an editor with `"doc_comments": {"strong":
true}` configured, the completions I get on `myClass` are exactly the
properties I'd expect (prototype and instance properties). Could you
maybe reduce the test case further, to a few lines that demonstrates a
specific problem?

> --
> You received this message because you are subscribed to the Google Groups
> "tern-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to tern-dev+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.