<div dir="ltr"><div dir="ltr">On Sun, Jan 13, 2019 at 5:49 AM Nathan Ridge <<a href="mailto:zeratul976@hotmail.com">zeratul976@hotmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Sam,<br>
<br>
Thanks for your feedback!<br>
<br>
> Regarding supertypes: editor support and standardization are both at <br>
> a very early stage. On the other hand, it's a useful feature that's easy to <br>
> implement[1]<br>
> <br>
> [1] Assuming an AST-only implementation that will fail to find <br>
> supertypes when the current file sees only a class's forward declaration.<br>
<br>
Indeed, that is how my current implementation works.<br>
<br>
>From a user point of view, it would be nice if it worked on types that are only forward-declared; once we figure out subtypes, we can probably extend supertypes to apply the same approach.<br>
<br>
> One alternative to consider is implementing it as an extension to <br>
> FindReferences (the supertype -> subtype relationship is a type of <br>
> reference.) This might be easier to standardize, as it seems giving a <br>
> ref-type mask to FindReferences would enable a bunch of these types <br>
> of features (and editors could reuse UI with little effort). It's unclear to <br>
> me how important showing the whole hierachy is.<br>
<br>
I can see modelling subtypes as a type of reference. It's less clear for supertypes: if I have a class with five bases, I want to report five results in my query, but my class's name is only mentioned once.<br></blockquote><div>Good point - the references wouldn't mention the original class name, which is confusing.</div><div>Thinking about the physical layout of source code, to find (direct) bases today one can just go-to-def and then see the list.</div><div>So a reference-style list of bases doesn't add much value (though a hierarchical one still might).</div><div><br></div><div>And thinking more about the interaction - it seems that a type hierarchy that shows both base and derived classes might be most useful. Do you know why the super/sub types are proposed as separate methods?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Even for subtypes, this implementation approach does not seem sufficient for the current proposed API. Annotating references as bases gives me the locations of base-clauses, but the API wants the name of the derived type. I don't think we can reliably get from one to the other without building an AST for the file in question.<br></blockquote><div>Sorry, I did mean here exposing (an extension of) the reference API, rather than the suggested supertypes API. Not sure it's a good idea, but it'd be a different model.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
As far as the API itself is concerned, there is some logic in formulating the API in terms of references. I believe cquery supports extensions that return subsets of references which are calls, bases, etc. However, it does this in addition to supporting a type hierarchy query, and a type hierarchy view does seem to be popular in editors. (Just among the editors I know, Eclipse, VSCode, and IntelliJ all have one, with Theia soon to follow.)<br></blockquote><div>VSCode in particular seems to get all its structure-awareness from language servers. Do you know where it gets data for type hierarchy? Practically speaking, what VSCode wants seems to drive about 80% of what gets standardized.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Regarding hiding extensions:<br>
> [...]<br>
>  I'd suggest trying to adopt/encourage shared names for extensions <br>
> among the LSP community rather than namespacing, myself.<br>
<br>
That sounds reasonable.<br>
<br>
It sounds like, for the time being, I should go ahead and submit my current AST-only superTypes implementation for review, using the proposed standard name, and see what happens. I'll clean up the patch and do so.<br></blockquote><div>Sounds good, thanks!<br></div></div></div>