4 ms·

I think that particular issue could be solved with tooling - if you can autocomplete from “package name” to a given exported identifier, you must already have a

by fwlr 2y ago

I think that particular issue could be solved with tooling - if you can autocomplete from “package name” to a given exported identifier, you must already have a mapping from “package name” to “exported identifier” somewhere in your machine’s memory; duplicate this mapping and swap the keys for values, now “exported identifier” points to “package name” as well. But I do agree that it should be “from ‘foo’ import { … }”, because then the code would look nicer.

jeswin 2y ago
> I think that particular issue could be solved with tooling - if you can autocomplete from “package name” to a given exported identifier, you must already have a mapping from “package name” to “exported identifier” somewhere in your machine’s memory; duplicate this mapping and swap the keys for values, now “exported identifier” points to “package name” as well. Sorry I don't follow. What the "from ..." syntax does (when typing it) is to narrow down 10k possibilities (the set of all exported functions in all in-scope modules) down to a few dozen. How would this be possible otherwise? Illustration: Case 1: import <just about anything is possible here - can't auto suggest> Case 2: from fs import <only fs functions are in scope, start autosuggesting on keypress>
afiori 2y ago
I dislike the assumption that natural languages are a good base for the syntax of programming languages, In my personal contrarian opinion I would have wanted something along the lines of import "url" with {namedImport}, defaultImport; With other keywords like import assertion mixed at the same level import "url" assert {type:"js"} with {namedImport}, defaultImport; I admit that `with` is not a great choice...
everforward 2y ago
A core problem here is that modules are generally a unique key, but exported identifiers are not. My editor does what you're talking about, but can be unhelpful because if I type in "create" I get 83,000 results. That would be much more helpful if it were pre-filtered by module so I get 6 results instead.
- fwlr 2y ago
  I’m so used to fuzzy search at this point that it didn’t even occur to me, but yeah, you’re right. I guess tooling can still provide a solution - a snippet on “import”, where the first tab stop takes you to the module path string, and the next tab stop jumps back to inside the braces?

by fwlr 2y ago

jeswin 2y ago

> I think that particular issue could be solved with tooling - if you can autocomplete from “package name” to a given exported identifier, you must already have a mapping from “package name” to “exported identifier” somewhere in your machine’s memory; duplicate this mapping and swap the keys for values, now “exported identifier” points to “package name” as well. Sorry I don't follow. What the "from ..." syntax does (when typing it) is to narrow down 10k possibilities (the set of all exported functions in all in-scope modules) down to a few dozen. How would this be possible otherwise? Illustration: Case 1: import <just about anything is possible here - can't auto suggest> Case 2: from fs import <only fs functions are in scope, start autosuggesting on keypress>

afiori 2y ago

I dislike the assumption that natural languages are a good base for the syntax of programming languages, In my personal contrarian opinion I would have wanted something along the lines of import "url" with {namedImport}, defaultImport; With other keywords like import assertion mixed at the same level import "url" assert {type:"js"} with {namedImport}, defaultImport; I admit that `with` is not a great choice...

everforward 2y ago

A core problem here is that modules are generally a unique key, but exported identifiers are not. My editor does what you're talking about, but can be unhelpful because if I type in "create" I get 83,000 results. That would be much more helpful if it were pre-filtered by module so I get 6 results instead.

fwlr 2y ago
I’m so used to fuzzy search at this point that it didn’t even occur to me, but yeah, you’re right. I guess tooling can still provide a solution - a snippet on “import”, where the first tab stop takes you to the module path string, and the next tab stop jumps back to inside the braces?