I wish the offline symbol table for Slack namespaces could be improved

[문하람]

Currently, the offline symbol table for the Slack namespace does not include the Builder class, causing indexing and code completion to not work. I kindly request that this issue be addressed and the missing part be supplemented.

[Scott Wells]

Hi. The standard/system Apex types in the OST are mostly derived from the Salesforce Tooling REST API's completions?type=apex resource, so the contents of that namespace are based on Salesforce's own representation. IC2 has a facility for fixing and augmenting the response from that API as it has a significant number of issues and omissions, but so far I haven't added very many changes for the Slack namespace specifically because, prior to now, I haven't heard from anyone about issues with it.

Aside from the Builder class, can you please specify other issues you're seeing with the types from that namespace?

[문하람]

Aside from the Builder class, there are cases where OSTs are not created in some classes (ex. Slack.ChannelCreatedEvent.Channel). I haven't checked every case, but it seems that this is mainly happening in Inner Classes. I'll leave an issue if I have any further questions. Thank you.

‌

[Scott Wells]

I have made some progress on this for the next release, but there’s a fundamental issue with the way that Salesforce describes this namespace via the completions?type=apex Tooling API. Basically there is a very prominent pattern of same-named inner classes such as Builder, Item, Message, etc. The response to that API flattens names to a single level within the namespace and IC has a mechanism for moving inner types into the right place. While there are more than 100 inner types in the Slack namespace named Builder, only one is returned in that API response, and it’s the union interface of all 100 types named Builder. Similar with the other repeated inner types.

IC was assuming that any type moved from the top-level of a standard namespace to become an inner type of another top-level type in that namespace was unambiguous, so when I first added these inner type adjustments, only one was addressed for each distinct inner type name. I’ve updated IC to understand that an inner type can exist in multiple locations in the same namespace, but understand that the end result is still that unioned interface of all inner types named Builder in all places. On the positive side, that should allow references to resolve properly, but on the negative side, code completions for these types are going to be kind of muddy.

I looked at whether there might be an easy (or even moderate) way to extract only the relevant subset of that unioned interface for each usage, but it’s not.

I’ll let Salesforce know about these issues with their API response, but short of hand-coding the entire Slack namespace – at least with regard to these ambiguous inner classes which are very large in quantity – what I’ve done right now is probably as good a solution as I’ll be able to provide.

These changes should be available in the next released build.

[문하람]

Thanks. I'm always rooting for you.

[Scott Wells]

Delivered in 2.3.0.2. Please read the release notes carefully for what has been addressed and what has not. For additional issues with types in this namespace other than the known one with these inner classes being union'ed interfaces, please log a new case here in the public issue tracker with details for those issues.