Understanding the use cases of the Poly Symbol API compared to the PSI Reference, etc. API

Is it expected the new Poly Symbol API will largely supplant the existing method for implementing languages (currently using PsiNameIdentifierOwner, PsiReference)? Or is it really only designed for cases where that existing method runs into limitations?

The documentation for the Poly Symbol API notes that “most of the aspects of support based on reference resolution, like find usages, documentation, or rename refactoring, will work out-of-the-box”. Currently, many of these feel like separate implementations with via different plugin providers. If the Poly Symbol approach will simplify these implementations, I would like to try that route. Unfortunately, since Poly Symbols are relatively new (and experimental), explanations on how to use them and what specifically they’re useful for are still a bit sparse. And this is why I’m asking here. I was hoping to find out if it’s worth delving into deeply enough to try an implementation. Please let me know!

Thank you for your time!

From what I understand for language design you still need PsiReference and may be Symbols but not the new API. Poly Symbol API simplifies life for references that can be contributed externally by plugins for things such as String literals or data languages (JSON/XML/YAML) where the language does not control the semantics of constructs.

1 Like