I heard recently some advice to "unimport an implicit conversion from Predef" - I presume that this means it is possible to unimport unwanted classes too:
import java.awt._
unimport java.awt.List
But this is not the syntax of an "unimport" (i.e. there is no such unimport keyword). What is the correct syntax?
Use the import alias feature but rename the "unwanted class" to "_". Since "_" can not be accessed in Scala code as a classname, it hides the renamed class from unqualified access.
import java.awt.{List => _, _}
Related
Looking for best Scala-Lang practice for import statements. Don't see any recommendation here:
https://docs.scala-lang.org/style/naming-conventions.html#packages
https://github.com/scala/scala
So what is recommended?
Option (1):
import package._
Option (2):
import package.ClassName
This is generally a matter of taste, but there is an argument for avoiding ._ so that the code is more robust to library changes that might introduce unwanted symbols into your code or create other subtle changes to your code that are difficult to track down.
Regarding implicits, wildcard imports have a potential advantage in that the name of the implicit can change without having to fix the import statements, for example, consider
object Qux {
object Implicts {
implicit class ExtraListOps[T](l: List[T]) {
def shuffle: List[T] = scala.util.Random.shuffle(l)
}
}
}
import Qux.Implicts._
List(1,2,3,4,5).shuffle
Here we could rename ExtraListOps and yet would not have to modify import statement. On the other hand, Joshua Suereth states:
You can pull implicits in individually without wildcards. Explicit
imports have 'priority' over wildcard imports. Because of this, you
can shadow wildcard imports with an explicit import.
Also consider the discussion in the SIP Wildcard imports considered harmful, where for example, Ichoran states
Superfluous clutter at the top of every file that can only be managed
by an IDE, and even then not very well, is something I find a lot more
harmful in most cases. If you get conflicting implicits and the
compiler doesn’t tell you exactly where they came from, that’s a
compiler issue. Once detected, the fix is easy enough (e.g. import org.foo.{troublesomeImplicit => _, _}).
I am new to scala. I am looking through some code and came up with a code that imports com.infinite.usermanagement.controllers.{ SecurityService => BaseSecurityService } package. I was wondering what does => sign means in an import.
This line means you import the class SecurityService and rename it to BaseSecurityService. You can use this to prevent name conflicts, etc. You can use this class by using BaseSecurityService instead of the original class name.
A very common example is the following (to prevent mixing up Scala and Java classes):
import java.util.{Map => JMap, List => JList}
As others have mentioned, it's an import rename. There is however one further feature that proves astoundingly-useful on occasion that I would like to highlight: If you "rename" to _, the symbol is no longer imported.
This is useful in a few cases. The simplest is that you'd like to do a wildcard import from two packages, but there's a name that's defined in both and you're only interested in one of them:
import java.io.{ File=>_, _ }
import somelibrary._
Now when you reference File, it will unambiguously use the somelibrary.File without having to fully-qualify it.
In that case, you could have also renamed java.io.File to another name to get it out of the way, but sometimes you really do not want a name visible at all. This is the case for packages that contain implicits. If you do not want a particular implicit conversion (e.g. if you'd rather have a compile error) then you have to delete its name completely:
import somelibrary.{RichFile => _, _}
// Files now won't become surprise RichFiles
The following example fails because the definition for Stuff can't be found:
package com.example
import javax.script.ScriptEngineManager
object Driver5 extends App {
case class Stuff(s: String, d: Double)
val e = new ScriptEngineManager().getEngineByName("scala")
println(e.eval("""import Driver5.Stuff; Stuff("Hello", 3.14)"""))
}
I'm unable to find any import statement that allows me to use my own classes inside of the eval statement. Am I doing something wrong? How does one import classes to be used during eval?
EDIT: Clarified example code to elicit more direct answers.
The Scripting engine does not know the context. It surely can't access all the local variables and imports in the script, since they are not available in the classfiles. (Well, variable names may be optionally available as a debug information, but it is virtually impossible to use them for this purpose.)
I am not sure if there is a special API for that. Imports are different across various languages, so bringing an API that should fit them all can be difficult.
You should be able to add the imports to the eval-ed String. I am not sure if there is a better way to do this.
I have several implicit context for my application.
like
import scala.collection.JavaConversions._
import HadoopConversion._
etc
Right now I have to copy paste all those imports at each file. Is it possible to combine them in one file and make only one import?
A good technique that some libraries provide by default is bundling up implicits into a trait. This way you can compose sets of implicits by defining a trait that extends other implicit bundling traits. And then you can use it at the top of your scala file with the following.
import MyBundleOfImplicits._
Or be more selective by mixing it in only where you need it.
object Main extends App with MyBundleOfImplicits {
// ...
}
Unfortunately with something like JavaConversions, to use this method you will need to redefine all the implicits you want to use inside a trait.
trait JavaConversionsImplicits {
import java.{lang => jl}
import java.{util => ju}
import scala.collection.JavaConversions
implicit def asJavaIterable[A](i : Iterable[A]): jl.Iterable[A] = JavaConversions.asJavaIterable(i)
implicit def asJavaIterator[A](i : Iterator[A]): ju.Iterator[A] = JavaConversions.asJavaIterator(i)
}
trait MyBundleOfImplicits extends JavaConversionsImplicits with OtherImplicits
Scala does not have first-class imports. So the answer to your question is no. But there is an exception for the scala REPL. You can put all your imports in a file and then just tell the REPL where it is located. See this question.
The other answers/comments are already comprehensive. But if you just want to reduce COPY/PASTEs, all mainstream IDE/text-editors support text templating ('live template' in IntelliJ IDEA, 'template' in Eclipse, 'snippets' in TextMate ...) that will definitely make your life easier.
I am working on a small Scala project. I have the following issue with 'import':
If, at the top of one of my files, I import two thing with these commands:
import main.Main._
import main.game.Game
^^^^
it gives me the following error message at the underlined 'main' word: "missing arguments for method main in object Main; follow this method with `_' if you want to treat it as a partially applied function" which is quite strange especially that it is just an import statement. And naturally no actual importing occures. At first I thought about semicolon inference quirks again but it is not the case. If I swap the two lines and write like this:
import main.game.Game
import main.Main._
then everythinng is fine.
Could anyone shed some light on that? Is it something special about Scala?
Presumably you have a main method in object Main. So after import main.Main._ main refers to this method instead of the main package. You could avoid it in several ways:
Change import order, as in the question.
Don't import the main method, as Daniel C. Sobral's answer suggests.
Explicitly say you want the top-level main package:
import _root_.main.game.Game
Following the normal Java package naming convention should avoid this problem in most cases, as you are unlikely to have members (or subpackages) called com or org (though net could be a problem).
You do have a method named main inside main.Main, don't you? Well, since you imported it, it has now shadowed the package by the name main. You can try this to confirm:
import main.Main.{main => _, _}
import main.game.Game
This will exclude main from being imported.