5 ms·

It's worth thinking about. Nowadays many people are letting their IDE do 90% of import statement maintenance, and then folding the lines out of the way so they

It's worth thinking about. Nowadays many people are letting their IDE do 90% of import statement maintenance, and then folding the lines out of the way so they don't have to bother reading them. That suggests to me that having explicit imports at the top of every file isn't the best representation of the information they contain. As far as naming is concerned, maybe it would be better to share a description of the project's naming rules in some larger scope, and let individual files override that. In languages where imports are doing work for dependency resolution as well as naming, maybe it would be more readable to have this information in one place than scattered around many files.

8note 5y ago
Import problems tend to get caught at code review time > are you sure you want to use com.do.not.use.this.is.a.copy.collection ?
fiddlerwoaroof 5y ago
I find passing dependencies via constructor arguments make codebases a lot easier to navigate: it encourages a pattern where you have a single file that wires up the entire system and you can look at that file to get a sense of which modules are talking to which other modules. Gilad Bracha had some interesting posts that talk about this pattern: https://gbracha.blogspot.com/2009/06/ban-on-imports.html?m=1 https://gbracha.blogspot.com/2009/06/ban-on-imports.html?m=1
- colanderman 5y ago
  I find that pattern makes navigation harder, particularly in untyped languages: because the particular implementation is now no longer statically resolvable, now I have to walk up a call tree to find which implementation (or even, which type, in an untyped language) corresponds to each of those constructor arguments, rather than just looking at the top of the file.
  - fiddlerwoaroof 5y ago
    I think this indicates bad modularity in the codebase and/or badly specified interface contracts. I’ve found that this makes finding bugs easier because I can start in the wiring file and then drill down to the only code that handles stuff relevant to the bug: by giving one place that lays out the high-level structure of a codebase, that place becomes like the “table of contents” for the rest of the code. This particular benefit is almost completely destroyed by DI frameworks that use annotations and other magic to automatically wire together a codebase. So, I just don’t use those.
- EdwardDiego 5y ago
  Constructor args are the simplest form of dependency injection :) And when I'm using a DI framework, the only injection point I'm happy with. But, having worked on a large codebase that used constructors with no DI framework, it makes adding a new dependency used in multiple bottom nodes of the graph very painful.
- wonnage 5y ago
  It’s super painful to figure out where this magically injected dependency came from. Now you have to look at every place that the object was constructed. And god forbid those constructors also use injected dependencies. I hate Guice.
  - fiddlerwoaroof 5y ago
    The solution here is not to use something like Guice and to only call the constructor once.
kerblang 5y ago
The folding would be mostly unnecessary if we wildcarded (e.g. `import foo.bar.*`) instead of explicitly spelling every single thing out, but many dev teams forbid that... and then want the IDE to compensate for it. My point actually being that if folks won't accept wildcards to begin with, I can't imagine importlessness gaining any traction, although perhaps we'll bifurcate as happened with the extremes of checked-exceptions-everywhere vs. never-exceptions.
armchairhacker 5y ago
I honestly think having the IDE resolve imports and then fold them is a good solution. The users don’t need to know the specific imports 90% of the time, but it really helps the compiler. So it’s a sort of metadata for the code, something we don’t really have. Usually, the same code is seen by both developer and compiler. (It may also help incoming developers, but personally i think it’s negligible. Now they just have module+identifier instead of identifier. The real help comes from “view symbol documentation” “jump to source” which is there regardless).

8note 5y ago

Import problems tend to get caught at code review time > are you sure you want to use com.do.not.use.this.is.a.copy.collection ?

fiddlerwoaroof 5y ago

I find passing dependencies via constructor arguments make codebases a lot easier to navigate: it encourages a pattern where you have a single file that wires up the entire system and you can look at that file to get a sense of which modules are talking to which other modules. Gilad Bracha had some interesting posts that talk about this pattern: https://gbracha.blogspot.com/2009/06/ban-on-imports.html?m=1 https://gbracha.blogspot.com/2009/06/ban-on-imports.html?m=1

colanderman 5y ago
I find that pattern makes navigation harder, particularly in untyped languages: because the particular implementation is now no longer statically resolvable, now I have to walk up a call tree to find which implementation (or even, which type, in an untyped language) corresponds to each of those constructor arguments, rather than just looking at the top of the file.
- fiddlerwoaroof 5y ago
  I think this indicates bad modularity in the codebase and/or badly specified interface contracts. I’ve found that this makes finding bugs easier because I can start in the wiring file and then drill down to the only code that handles stuff relevant to the bug: by giving one place that lays out the high-level structure of a codebase, that place becomes like the “table of contents” for the rest of the code. This particular benefit is almost completely destroyed by DI frameworks that use annotations and other magic to automatically wire together a codebase. So, I just don’t use those.
EdwardDiego 5y ago
Constructor args are the simplest form of dependency injection :) And when I'm using a DI framework, the only injection point I'm happy with. But, having worked on a large codebase that used constructors with no DI framework, it makes adding a new dependency used in multiple bottom nodes of the graph very painful.
wonnage 5y ago
It’s super painful to figure out where this magically injected dependency came from. Now you have to look at every place that the object was constructed. And god forbid those constructors also use injected dependencies. I hate Guice.
- fiddlerwoaroof 5y ago
  The solution here is not to use something like Guice and to only call the constructor once.

kerblang 5y ago

The folding would be mostly unnecessary if we wildcarded (e.g. `import foo.bar.*`) instead of explicitly spelling every single thing out, but many dev teams forbid that... and then want the IDE to compensate for it. My point actually being that if folks won't accept wildcards to begin with, I can't imagine importlessness gaining any traction, although perhaps we'll bifurcate as happened with the extremes of checked-exceptions-everywhere vs. never-exceptions.

armchairhacker 5y ago

I honestly think having the IDE resolve imports and then fold them is a good solution. The users don’t need to know the specific imports 90% of the time, but it really helps the compiler. So it’s a sort of metadata for the code, something we don’t really have. Usually, the same code is seen by both developer and compiler. (It may also help incoming developers, but personally i think it’s negligible. Now they just have module+identifier instead of identifier. The real help comes from “view symbol documentation” “jump to source” which is there regardless).