According to this I should be able to have multiple import statements like this:
import class1, class2, class3, class4
Class MyApp.MyClass {}
The code compiles with one import, but as soon as I place more than one the code fails to compile.
What is the correct syntax?
I can't find it in the documentation, but
import (class1, class2, class3, class4)
Class MyApp.MyClass {}
seems to work.
documentation
more than one package, you need to take in brackets
Related
I'm learning java and I'm told this package is provided by default, to every class, because its methods are so common. I thought I would try to import it, any way to see what would happen. I know its not practical and probably expensive but I'm curious as to why it's doesn't work from a technical point of view.
import javax.lang.*;//why doesn't this work.
javax.lang contains only a single package: model
https://docs.oracle.com/javase/7/docs/api/index.html?javax/lang/model/package-summary.html
you're not doing anything by importing this package. Maybe you're confusing it with java.lang ?
You don't need to import java.lang.*
There is one exception to the import rule. All classes in the java.lang package are imported by default. Thus you do not need to import java.lang.*; to use them without fully qualified names.
Consider the System.out.println() method we've been using since the first day of class.
System is really the java.lang.System class. This class has a public static field called out which is an instance of the java.io.PrintStream class. So when you write System.out.println(), you're really calling the println() method of the out field of the java.lang.System class.
I would like to define an implicit conversion from Iterator[T] to a class that I have defined: ProactiveIterator[A].
The question isn't really how to do it but how to do it properly, i.e. where to place the method, so that it is as transparent and unobtrusive as possible. Ideally it should be as the implicit conversion from String to StringOps in scala.Predef If the conversion was from a class in the library to some other class, then it could be defined inside that class, but AFAIK that's not possible here.
So far I have considered to add an object containing these conversions, similarly to JavaConversions, but better options may be possible.
You don't really have much of a choice. All implicits must be contained within some sort of object, and imported with a wildcard import (you could import them individually, but I doubt you want that).
So you'll have some sort of implicits object:
package foo.bar
object Implicits {
implicit class ProactiveIterator[A](i: Iterator[A]) {
...
}
}
Then you must explicitly import it wherever you use it:
import foo.bar.Implicits._
In my opinion, this is a good thing. Someone reading the code might not understand where your pimped methods are coming from, so the explicit import is very helpful.
You can similarly place your implicits within a package object. You would have to import them the same way into other namespaces, but they would be available to classes within the same package.
For example, using the following, anything within foo.bar will have this implicit class available:
package foo
package object bar {
implicit class ProactiveIterator[A](i: Iterator[A]) {
...
}
}
Elsewhere you would import foo.bar._ (which may or may not be as clean, depending on what's in bar).
Let's say I have a Scala project with a bunch of case classes under package com.example.a.b.c. I want to import all these classes into a package com.example.c (which contains a few more non-conflicting case classes) so that anywhere else in my project, I only need to import com.example.c._ to use every case class both from com.example.c and com.example.a.b.c.
How can I do that?
There is discussion of adding an export mechanism which would do what you want, but it's not clear whether that will happen.
In any case, for now the only way is to
Define the type of every class
Set a val equal to every object
So for example,
package bar
case class Foo(i: Int) {}
would need to be mimicked in another package with
package object baz {
type Foo = bar.Foo
val Foo = bar.Foo
}
When faced with this, people usually just settle for an extra import or two.
The import statement in scala just tells the compiler where to find other classes like in java, not like the #include directive in C/C++ where the compiler physically copies the entire header file. If you want to use the case classes from com.example.a.b.c, you should import them from their own package as this is the conventional way.
A very strange thing indeed. I have the following project structure:
myproject/one/two
Inside package myproject I have a class:
abstract class A (two: Buffer[Int])
and then, inside package one I have:
object B extends A (Buffer[Int](1, 2, 3)) {
val с = two.map(_ + 1) // ERROR
}
However, the erros says:
object map is not a member of package
myproject/one/two
which is obviously erroneous because it should be perfectly clear that I don't refer to the packages here, but to the local variable... And two also is not shown in context-assist after this. in B, but is shown in A (Scala-IDE). Is this an intended behavior and I am doing something wrong or is it a bug?
UPDATE:
(simultaneously suggested by Nicolas :D ) Been able to resolve the name collision by specifying two as val (making it public). I did not notice at first, but it was private and unavailable in the successor class. Nevertheless I am still wondering, why and how did Scala pick up a package instead of saying that the variable does not exist or is not accessible?
It's not as clear as you might think. Without a modifier, two is private to abstract class A class A. Thus your declaration of a is equivalent to abstract class A (private[this] A). It means that field two can't be seen from object B. A direct consequence is that the compiler look into the only defiition of two visible from B: the package two.
If I have a package com.example, I can create a class in that package like this:
package com.example {
class MyClass
}
or like this:
package com {
package object example {
class MyClass
}
}
In both cases, the resulting class is (as far as other Scala code is concerned, at least) com.example.MyClass.
There are certainly incidental differences. In the first instance, the resulting compiled class is com/example/MyClass.class whereas in the second it's com/example/package$MyClass.class but are there any substantive differences?
The difference in generated class file names was discussed on scala-internals, and hopefully will disappear in Scala 2.10.
The only reason I can think of is that instead of being able to put only classes, objects or types in a package, you can put defs, vals and vars in an object.