Project: aptanastudio
Issue APSTUD-7477: Adjust JS index keys to be inline with expected usage
When we decided to make use of the same index format as JDT, we expected to also retain similar usage. JS usage of the index falls pretty far outside of that by effectively serializing properties/functions/events/event properties using JSON. This can lead to very large "keys" and can make it nearly impossible to do easy queries using patterns for particular attributes. Currently we store type, function, property, event, require. The first four are simply the declarations. The last is a very specific instance of recording references to the 'require' function/method. JDT typically stores declarations with more details, but also stores references to types/fields/methods; and records references to supertypes/interfaces separate from the type declaration. Additionally, declaration keys are typically simple and compact. JDT: {code} type decl: typeName / packageName / enclosingTypeName / modifiers (modifiers are packed as an int, using 2 chars - and represent combo of class/interface/enum/annotation flag/markers) super ref: superSimpleName / superQualification / simpleName / enclosingTypeName / typeParameters / pkgName / superClassOrInterface classOrInterface modifiers field ref and decl: fieldName method: name / arity (arity is the arg/parameter count) {code} Studio: {code} property: name, description, since, user-agents, owning type, isClass, isInstance, isInternal, deprecated, types, examples function: all from property plus isConstructor, isMethod, parameters, returnTypes, exceptions, references. parameters (included in function): name, types, usage, description return-types/types: type, description exception: type, description event: name, description, since, user-agents, owning type, properties, deprecated event property: name, description, since, user-agents, type, deprecated {code} Obviously we store much more information and we expect to fully serialize the metadata from the index, whereas JDT uses the index for matching and then opens the defining document/file and parses to reconstruct when more details are necessary. Additionally we store type inferencing data in the index where JDT doesn't need to (it records type info in relavent index categories, but doesn't need to for fields/vars/methods as it can always easily look it up). The open question is whether we can do the same - and to do so what sort of information will we need to record in the index and what can we lookup on-demand?
Story points: 40