Type Hierarchy Implementation in reference-view

[CsCherrYY]

Original discussion: microsoft/language-server-protocol#1231 (comment)

We are working on supporting Type Hierarchy in language server protocol. The draft of Type Hierarchy looks like the existing call hierarchy one: a prepare request and two requests for the supertypes and the subtypes of the given type.

Besides, the type hierarchy would have a third view apart from the classic supertype/subtype view. For single inheritance languages like Java and C#, the most popular type hierarchy view by users is class view, which will show all the classes in the inheritance tree of the given class. To keep the protocol simple, we don't include this view in the current draft, and plan to support it in specific extensions (e.g. Java extension).

Currently, the java extension supports type hierarchy with all the three views through workspace commands, and users like it. So before migrating the existing implementation to the LSP, we should consider the three views (including class view, which will still be contributed by java extension using the API from reference-view) when drafting the protocol. So far, we have met some problems about the reference-view, where we want to implement the UI. We would like to discuss them here. @jrieken Could you please provide any feedbacks?

• Currently the java users are familiar with the class view as the default view, and it's indeed the most important view for them. Since the class view would be introduced by Java extension, while the supertype/subtype view would be supported in the reference-view itself, can we find a way to make the class view as the default view when the user is using Java?

• The java extension offers a setting to control whether to prefetch the children of an item, to assign its precise collapsibleState. If the prefetch is enabled, the view would be like this:
  
  You can see there is no arrow behind of an item if it has no children. Can we offer a similar setting in the reference-view to provide a better user experience?

• We find in the current implementation of call hierarchy, if there is no caller/callee of a given method, the collapsibleState of the item is still expanded, which may confuse users, since they don't know the method has caller/callee or not exactly.
  
  In the Java extension implementation, we base on the reference-view and just reset the collapsibleState of the item if it has no children.
  
  @Eskibear offers another approach to solve this problem, to use another state Unknown of collapsibleState. see: Can't update the collapse state in the references-viewlet #114614 (comment). I'm not sure which is the best approach to solve this problem.

cc: @dbaeumer @Eskibear

[dbaeumer]

IMO the reference view can support all three views and it can be some sort of configuration we do on the view. The protocol does support sub and super types and whether they are presented as a class view is a user decision and then a filtering on the client side.

[jrieken]

We now have native support for type hierarchy in the references view