4 ms·

I love Scala but the Intellij support is lacking in that it can't always find the right import to auto-import and I have to manually add it myself. I think it

I love Scala but the Intellij support is lacking in that it can't always find the right import to auto-import and I have to manually add it myself. I think it comes down to the fact that it takes the compiler a lot of cpu cycles to figure out what's actually in scope with implicits, etc. I soldier through it, but it can be annoying when I have to go hunting around for the import.

bad_user 11y ago
IntelliJ IDEA's auto-import works fine for normal imports. But it cannot guess what implicits you need imported in scope any more than the compiler can. The only implicit (I can think of) from the standard library that needs to be explicitly imported is ExecutionContext.Implicits.global. It's a form of dependency injection meant for working with Future and the error message tells you exactly what to do, but it can't be automatically imported because the thread-pool used is a pretty big deal and you should pause for a second to think about it. Other than that, the implicits you need are probably your own doing, because common libraries usually have a design where you get everything needed with sensible defaults. In other words, if it's painful to import, then you should probably rethink it. This is actually a very good rule for Java as well. People too often rely on IDEs to do the boring parts, not noticing the stench until it is too late.
- draven 11y ago
  As said on http://www.scala-lang.org/api/2.11.7/index.html#scala.concurrent.ExecutionContext http://www.scala-lang.org/api/2.11.7/index.html#scala.concur... the default global should not be imported all over the place. It's better to declare functions with an implicit ExecutionContext and try to declare your execution contexts in a few well-known places. The (web) app I'm working on uses several ExecutionContexts (database access has a specific one for example.)

bad_user 11y ago

IntelliJ IDEA's auto-import works fine for normal imports. But it cannot guess what implicits you need imported in scope any more than the compiler can. The only implicit (I can think of) from the standard library that needs to be explicitly imported is ExecutionContext.Implicits.global. It's a form of dependency injection meant for working with Future and the error message tells you exactly what to do, but it can't be automatically imported because the thread-pool used is a pretty big deal and you should pause for a second to think about it. Other than that, the implicits you need are probably your own doing, because common libraries usually have a design where you get everything needed with sensible defaults. In other words, if it's painful to import, then you should probably rethink it. This is actually a very good rule for Java as well. People too often rely on IDEs to do the boring parts, not noticing the stench until it is too late.

draven 11y ago
As said on http://www.scala-lang.org/api/2.11.7/index.html#scala.concurrent.ExecutionContext http://www.scala-lang.org/api/2.11.7/index.html#scala.concur... the default global should not be imported all over the place. It's better to declare functions with an implicit ExecutionContext and try to declare your execution contexts in a few well-known places. The (web) app I'm working on uses several ExecutionContexts (database access has a specific one for example.)