Jump to page: 1 2
Thread overview
Cool project idea: organise/remove imports
Jul 11
Monkyyy
Jul 16
RazvanN
Jul 16
RazvanN
July 11

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.

July 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.

July 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:
> > 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.

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 Davis



July 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?

July 12

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.

July 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:

>

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?

This is an important question

July 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

July 15

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:

>

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.

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.

July 15

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:

>

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?

This to me sounds like it should be in tools, not Phobos.

July 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.

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.

« First   ‹ Prev
1 2