Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Imported-via feature #9

Open
robinp opened this issue Oct 6, 2019 · 3 comments
Open

Imported-via feature #9

robinp opened this issue Oct 6, 2019 · 3 comments
Labels
enhancement New feature or request kythe-backend

Comments

@robinp
Copy link
Member

robinp commented Oct 6, 2019

For languages that have blanket-import-everything-from-module [1], the UI could indicate what are the actually used bindings at a blanket-import.

Reverse, given a usage, the UI could indicate (via highlight, and/or in backrefs) which import was used to bring it in scope.

See inspiration in google/haskell-indexer#100.

[1]: Haskell for sure. ML's open structure syntax? Java's import static foo.*?

@robinp robinp added the enhancement New feature or request label Oct 6, 2019
@kamahen
Copy link

kamahen commented Oct 7, 2019

Python:

from os.path import *
print(sep)

In this, sep comes from the "import" line. Should the ref resolve to the "*" in that line or should it resolve to the place in file os/path.py that defines sep?

As a related issue:

import os.path.sep as os_path_sep
print(os_path_sep)

Should os_path_sep in the 2nd line resolve to the os_path_sep in the 1st line? From the language definition, the 1st line acts like a defines/binding (because it adds an entry to the variables' dictionary); but it could be argued that it's more natural when clicking on the 2nd os_path_sep to resolve that to the definition of sep in os/path.py; or it could be both.

UI design is hard (and so is schema design).

@robinp
Copy link
Member Author

robinp commented Oct 7, 2019

@kamahen this exact issue seems to be addressed by (see the exact comment) kythe/kythe#4021 (comment), and the more lengthy kythe/kythe#3934 (comment): the os_path_sep should

  • both have a define/binding to a local variable/import, and then usage refer that one,

  • and also a ref to the semantic entity of the os.path.sep module,

  • and the two semantic entities (the local and the global module one) connected via aliases edge.

That one is pretty sure. Now, for the import * one, there's a tradeoff:

  • The semantically nice thing is, I think, that the * anchor should do again the same (emit both defines/binding and a ref), but for all the imported names.

  • But that might not be practical - if a module exports hundreds of names, but only one is actually used, why emit the other 99? Adds lots of noise. So for this feature to be practical, I believe the indexer should strive to emit only the used names.

(Note that #10 covers this usecase in more detail)

@robinp
Copy link
Member Author

robinp commented Oct 7, 2019

With all the new info about aliased imports, I now think this feature is deprecated, and the indexers should rather emit explicit edges for used imports even in blanket / implicit imports.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request kythe-backend
Projects
None yet
Development

No branches or pull requests

2 participants