Community
Participate
Working Groups
For a following code: /** * @constructor */ Type1 = function() {} Type1.prototype.coolDynFunc = function() {} Type2 = Type1; Both Type1 and Type2 should be recognized as types with a constructor and coolDynFunc member. So in Outline user should see: -Type1 +- Type1() +- coolDynFunc() -Type2 +- Type2() +-coolDynFunc() and in content assist both types should be supported equally.
Created attachment 172199 [details] patch a dirty way to do that is simply copy the original type. I call it dirty, because copying one object to another seems a wrong solution. Unfortunately currently there seems no easy way to express that more than one name points to an existing type. When copying functions, special handling is required for constructor, to make sure it has the same name as containing type.
Created attachment 173282 [details] patch v2 updated patch to better handle methods, attributes and mixins.
This patch is no longer applying cleanly and I can't figure out where it is supposed to go. Are we sure that we always want to copy the object if the right hand side is inferred as a type? Seems like an awfully broad condition.
hi Chris, no, the patch is not perfect, that was the smallest change I could think of within JSDT model. We added this in some adopter product and so far it worked well enough. The better solution than copy would be to keep only one instance of type definition and list of names referring to that type.
Created attachment 191398 [details] proof of concept only Technically, wouldn't it be more correct to simply have the fields of Type2's InferredType be assigned the fields from Type1's InferredType?
I recall a few issues: 1. constructor. If we copy type A to type B, then constructor method ("A()") was no longer recognized as constructor but as a regular function B.A(). So in patch, I was updating constructor method name from A.A() to B.B(). 2. type methods I tried simple dest.methods = src.method on inferred types, but this was causing visible problems in content assist. More precisely, method parameter names were not recognized correctly - e.g. for "A.each(func)" was "B.each(arg0)" instead of "B.each(func)". (will attach screenshot) This was caused by the way how attributes names were read - taking into account both method AST and parent type. (Not sure if this is an issue anymore) 3. type attributes In earlier patch I see that I tried dest.attributes = src.attributes on inferred types too. But when making changes related to methods (pt 2. above), I changes attributes similarly as well... so probably there was similar issue with attributes too, but I don't have details any more.
Created attachment 191401 [details] screenshot screenshot showing the issue with method parameters, in previous comment
Created attachment 191402 [details] screenshot wrong screenshot...
Retaining the argument names properly is certainly something that needs to be done (along with any jsdoc we might have found while parsing). Was that problem seen when trying your patch or mine?
