digitalmars.D - Cool project idea: organise/remove imports
- Atila Neves (6/6) Jul 11 It'd be amazing if one could hit a key/key combination and have
- Alexandru Ermicioi (6/12) Jul 11 That must be one of core features not just amazing.
- Jonathan M Davis (18/31) Jul 11 We could certainly get partway there, but I'm not sure that it's even
- Monkyyy (3/9) Jul 11 If I wrote a script that mostly worked would it be merged on
- Imperatorn (2/12) Jul 12 This is an important question
- Atila Neves (2/12) Jul 15 This to me sounds like it should be in tools, not Phobos.
- Vladimir Panteleev (16/19) Jul 12 I made this a while ago. It's not quite what you describe -
- Guillaume Piolat (3/11) Jul 12 +1
- Atila Neves (9/28) Jul 15 Nice!
- Quirin Schroll (5/11) Jul 16 String mixins immediately make that a best-effort solution. Even
- RazvanN (18/24) Jul 16 I have a small program that uses dmd as a library that:
- RazvanN (3/10) Jul 16 Forgot to provide a link:
It'd be amazing if one could hit a key/key combination and have all imports pared down to the absolute minimum (and made local). If only I had the time... Imagine being lazy, typing "import std;" at module-scope, writing some code and... boom. "Hand-written" local imports everywhere. One can dream.
Jul 11
On Thursday, 11 July 2024 at 10:28:35 UTC, Atila Neves wrote:It'd be amazing if one could hit a key/key combination and have all imports pared down to the absolute minimum (and made local). If only I had the time... Imagine being lazy, typing "import std;" at module-scope, writing some code and... boom. "Hand-written" local imports everywhere. One can dream.That must be one of core features not just amazing. Java, php, typescript, kotlin, groovy, and any other language with good ide functionality have this. As reference on feature set and configurability I'd suggest to look at java import optimizer found in Jetbrains IDE.
Jul 11
On Thursday, July 11, 2024 4:43:28 AM MDT Alexandru Ermicioi via Digitalmars-d wrote:On Thursday, 11 July 2024 at 10:28:35 UTC, Atila Neves wrote:We could certainly get partway there, but I'm not sure that it's even actually possible in D to get all of the way there thanks to templates and conditional compilation. You can create local imports for non-templated stuff, and for the conditional code branches that are actually compiled, you could add local imports, but removing the top-level imports would break the uncompiled conditional branches in many cases, and since what happens with those conditional branches depends on state that you don't necessarily have access to, you can't necessarily automate adding the correct imports - at least not if you want to actually use selective imports rather than just copying all of the top-level imports which _might_ be needed. Attempts have been made in the past to do stuff like provide a tool for removing unused imports (which is essentially the same problem), and they've never fully worked, because D's conditional compilation gets in the way. It's the kind of thing that's much easier to do with a simpler, less powerful language. - Jonathan M DavisIt'd be amazing if one could hit a key/key combination and have all imports pared down to the absolute minimum (and made local). If only I had the time... Imagine being lazy, typing "import std;" at module-scope, writing some code and... boom. "Hand-written" local imports everywhere. One can dream.That must be one of core features not just amazing. Java, php, typescript, kotlin, groovy, and any other language with good ide functionality have this. As reference on feature set and configurability I'd suggest to look at java import optimizer found in Jetbrains IDE.
Jul 11
On Thursday, 11 July 2024 at 10:28:35 UTC, Atila Neves wrote:It'd be amazing if one could hit a key/key combination and have all imports pared down to the absolute minimum (and made local). If only I had the time... Imagine being lazy, typing "import std;" at module-scope, writing some code and... boom. "Hand-written" local imports everywhere. One can dream.If I wrote a script that mostly worked would it be merged on phoboes?
Jul 11
On Thursday, 11 July 2024 at 21:04:58 UTC, Monkyyy wrote:On Thursday, 11 July 2024 at 10:28:35 UTC, Atila Neves wrote:This is an important questionIt'd be amazing if one could hit a key/key combination and have all imports pared down to the absolute minimum (and made local). If only I had the time... Imagine being lazy, typing "import std;" at module-scope, writing some code and... boom. "Hand-written" local imports everywhere. One can dream.If I wrote a script that mostly worked would it be merged on phoboes?
Jul 12
On Thursday, 11 July 2024 at 21:04:58 UTC, Monkyyy wrote:On Thursday, 11 July 2024 at 10:28:35 UTC, Atila Neves wrote:This to me sounds like it should be in tools, not Phobos.It'd be amazing if one could hit a key/key combination and have all imports pared down to the absolute minimum (and made local). If only I had the time... Imagine being lazy, typing "import std;" at module-scope, writing some code and... boom. "Hand-written" local imports everywhere. One can dream.If I wrote a script that mostly worked would it be merged on phoboes?
Jul 15
On Thursday, 11 July 2024 at 10:28:35 UTC, Atila Neves wrote:It'd be amazing if one could hit a key/key combination and have all imports pared down to the absolute minimum (and made local). If only I had the time...I made this a while ago. It's not quite what you describe - instead of typing `import std;`, you don't type any imports at all, and instead the tool uses compiler error messages + `.json` output to add missing imports. https://forum.dlang.org/post/baayfburkivhwurpepav forum.dlang.org Code is here: https://github.com/CyberShadow/AutoFix (now includes an Emacs package). I'm not sure that local imports are best for all cases. They're good for trivial things like pure parsing functions wanting to import some utility module. Otherwise, having them at the top of the module is a good way to document and understand the relationships of the module with other parts of the program - for instance, networking imports tell you right away that it talks to other things on the network, filesystem imports tells you it uses files, same with custom subsystems.
Jul 12
On Friday, 12 July 2024 at 09:37:46 UTC, Vladimir Panteleev wrote:I'm not sure that local imports are best for all cases. They're good for trivial things like pure parsing functions wanting to import some utility module. Otherwise, having them at the top of the module is a good way to document and understand the relationships of the module with other parts of the program - for instance, networking imports tell you right away that it talks to other things on the network, filesystem imports tells you it uses files, same with custom subsystems.+1 I tend to always remove local imports now
Jul 12
On Friday, 12 July 2024 at 09:37:46 UTC, Vladimir Panteleev wrote:On Thursday, 11 July 2024 at 10:28:35 UTC, Atila Neves wrote:Nice! I think local imports are always superior, because they help with refactoring. I've had DCD choke on where certain symbols come from as well and have lost count of how many times I've had to localise and make explicit every import in order to find out. It's also easier to hide dependencies in module-level imports. A function with 20 imports is clearly doing something wrong but that doesn't stand out if all of them are at module level instead.It'd be amazing if one could hit a key/key combination and have all imports pared down to the absolute minimum (and made local). If only I had the time...I made this a while ago. It's not quite what you describe - instead of typing `import std;`, you don't type any imports at all, and instead the tool uses compiler error messages + `.json` output to add missing imports. https://forum.dlang.org/post/baayfburkivhwurpepav forum.dlang.org Code is here: https://github.com/CyberShadow/AutoFix (now includes an Emacs package). I'm not sure that local imports are best for all cases. They're good for trivial things like pure parsing functions wanting to import some utility module. Otherwise, having them at the top of the module is a good way to document and understand the relationships of the module with other parts of the program - for instance, networking imports tell you right away that it talks to other things on the network, filesystem imports tells you it uses files, same with custom subsystems.
Jul 15
On Thursday, 11 July 2024 at 10:28:35 UTC, Atila Neves wrote:It'd be amazing if one could hit a key/key combination and have all imports pared down to the absolute minimum (and made local). If only I had the time... Imagine being lazy, typing "import std;" at module-scope, writing some code and... boom. "Hand-written" local imports everywhere. One can dream.String mixins immediately make that a best-effort solution. Even if you run the mixins, their result might depend on your platform or whatnot and require other imports on other platforms that are unused on your platform.
Jul 16
On Thursday, 11 July 2024 at 10:28:35 UTC, Atila Neves wrote:It'd be amazing if one could hit a key/key combination and have all imports pared down to the absolute minimum (and made local). If only I had the time... Imagine being lazy, typing "import std;" at module-scope, writing some code and... boom. "Hand-written" local imports everywhere. One can dream.I have a small program that uses dmd as a library that: - identifies unused global imports - provides a list of the symbols that are being used for each global import It can easily be updated to also store the location for each of the usage sites for the imported symbols. By having the location you can approximate in what function you are in. That being said, it's not going to work with alias declarations and enums because those are eagerly substituted by the compiler when doing semantic analysis (the tool traverses the tree after sema was performed). I think this small script can be used to at least automatically transform global imports into selective ones. The fundamental problem with dmd as a library is that we still can't properly hook into the compiler internals. We are stuck to performing sema and then trying to extract information from the enriched tree, which kind of sucks. RazvanN
Jul 16
On Tuesday, 16 July 2024 at 15:25:39 UTC, RazvanN wrote:On Thursday, 11 July 2024 at 10:28:35 UTC, Atila Neves wrote:Forgot to provide a link: https://github.com/RazvanN7/Unused-Import/blob/master/unused_import.d .[...]I have a small program that uses dmd as a library that: - identifies unused global imports - provides a list of the symbols that are being used for each global import [...]
Jul 16