Uploaded image for project: 'Aptana Studio'
  1. Aptana Studio
  2. APSTUD-7477

Adjust JS index keys to be inline with expected usage

    Details

    • Type: Story
    • Status: Open
    • Priority: Low
    • Resolution: Unresolved
    • Affects Version/s: Aptana Studio 3.3.0
    • Fix Version/s: None
    • Component/s: Indexing, JS
    • Labels:
      None
    • Story Points:
      40

      Description

      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:

      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)
      

      Studio:

      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
      

      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?

        Attachments

          Activity

            People

            • Assignee:
              pinnamuri Praveen Innamuri (Inactive)
              Reporter:
              cwilliams Christopher Williams
            • Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:

                Git Source Code