This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
The provided example is a slightly modified of the reference JsDoc wiki one. I added @method, @type, @return to exclude method parsing from problems. We expect that the pattern understand that all the literal is working inside the class scope, either instance or prototype. In fact, in this pattern is accepted "initialize" and "constructor", the created members should be available to "instance scope" inside the literal. Inside the literal, the methods are shown correctly, with docs, and types but after return, they loose the scope. Seems like parser forget that the result was being deployed into "this" scope, or worst, never have idea of what was the "this" scope at all after returning the value. "this" issue is whole topic, but we can go further fixing this bug. /** * @constructor */ FOO.Screen = function () { } Ext.extend ( FOO.Screen, FOO.Device, /** * @scope FOO.Screen.prototype */ { /** * @method getArr * @return {Array} An Arr * @type Array */ getArr : function () { return []; }, other : function(){ this.getArr().window;//"some result ommited + global scope" } } )
It's also notable that the return type is also lost, by think we could do another report to that issue. I find the solution, "getArr" method should be documented like this. /** * Description text. * @method getArr * @return {Array} An Arr */ Conclusion: 1) @type tag is parsed like field value type, jsDoc handle that by understanding the nature of the "typed" block. Netbeans should either advice this fact or match jsDoc. 2) @method getArr, is needed (i plan to make a wiki on javascript doc, to help users) 3) Both description and return description are ensured, some tests fixes autocomplete when adding them.
Switching to enhancement since the scope wasn't supported yet. Actually currently we are parsing that tag, but there is more to do in the model and we haven't time for such improvements this release, sorry. Targeting to next release.
I think the parser should be "scope aware" at least try to be. Then the tag could "aid" the parser to define diffuse situations to separate instance time members from the static ones. Also the scope awareness could aid to return a proper type easily. Of course, this are just thoughts i don't know the internals of the engine.
(In reply to comment #3) > I think the parser should be "scope aware" at least try to be. > > Then the tag could "aid" the parser to define diffuse situations to separate > instance time members from the static ones. > > Also the scope awareness could aid to return a proper type easily. I agree with all of that. > Of course, this are just thoughts i don't know the internals of the engine. There are two parsers, one for the JS sources, second for the JS documentation. All results must be merged then. And currently we are hardly working on supporting at least the same features as were in the previous release but with the completely new (more buggy and extensible) JS editor. So there's not much place for new enhancement right now, sorry.