I subclassed org.scalatest.FlatSpec to add practical tooling to FlatTest. But anywhere I use this subclass, I have to import scala.language.reflectiveClass otherwise I get
reflective access of structural type member method test should be enabled
by making the implicit value scala.language.reflectiveCalls visible.
The method test in question is the equivalent to should in standard FlatSpec:
it should "do some stuff" in { ...}
Why is it not necessary to import reflectiveCalls to use flatSpec should but is necessary for my test method, and how can I avoid that?
The reason why you are getting this warning is that you have structural type reference or new {...} call somewhere in your test method.
Unfortunately there is no way to turn off that warning other than by explicit scala.language.reflectiveClass import or rewriting your code.
Related
I'm working on a commons library that includes a config library (https://github.com/kxbmap/configs).
This config library uses "kebab-case" when parsing configuration files by default and it can be overridden by an implicit def in scope.
However, I don't want to force that on the users of my commons library when they get access to the config library transitively.
So without me forcing users to import this implicit, like:
import CommonsConfig._
can I somehow override the naming strategy via an implicit that gets into scope by only including my commons library on the classpath. I'm guessing no but I just have to ask :)
So if not, is someone aware of another approach?
kxbmap/configs isn't that well documented to explain this.
Thanks!
Implicits work in compile time, so they cannot get magically present if something is included and then disappear if it isn't.
The closest thing would be something like:
main library
package my.library
// classes, traits, objects but no package object
extension
package my
package object library {
// implicits
}
user's code
import my.library._
however that would only work if there were no package object in main library, only one extension library could pull off this trick at once (Scala doesn't like more than one package object) and user would have to import everything available with a package, always.
In theory you could create a wrapper around all you deps, with your own configs:
final case class MyLibConfig(configsCfg: DerivationConfig)
object MyLibConfig {
implicit val default: MyLibConfig = ...
}
and then derive using this wrapper
def parseThings(args...)(implicit myLibConfig: MyLibConfig) = {
implicit val config: DerivationConfig = myLibConfig.config
// derivation
}
but in practice it would not work (parseThings would have to already know the target type or would need to have the already derived implicits passed). Unless you are up to writing your own derivation methods... avoid it.
Some way of making user just import all relevant stuff is the most maintainable strategy. E.g. you could pull off the same thing authors did and add type aliases for all types that you use, do the same for companion objects and finally put some implicits there:
package my
package object library {
type MyType = some.library.Type
val MyType = some.library.Type
implicit val derivationConfig: DerivationConfig = ...
}
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).
I encountered the following in Scala code:
class MyClass {
...
val a = new A; import a._
}
What does exactly val a = new A; import a._ mean ?
It imports the methods and variables of the a object. So if you want to call a.foo(), you can just call foo() instead.
It means that all methods and variables of a object of A type are now available in this block (scope) without explicitly mentioning a. So if A has a bar() method you can now say:
bar()
instead of
a.bar()
but only within the scope where import is defined.
Let's explain this with something you should be familiar with:
println("Hello world")
The question is: why does that work? There's no object called println with an apply method, which is the usual explanation for code that looks like that. Well, as it happens, the above code is really doing this:
Predef.println("Hello world")
In other words, println is a method on the object scala.Predef. So, how can you use it like above? Well, like this:
import scala.Predef._
println("Hello world")
Importing the contents of a stable reference (ie, not a var or a def) will make its methods available without having to prefix them with reference..
It also makes any implicits defined inside it available, which is how the implicit conversions defined inside scala.Predef are made available as well -- Scala imports the contents of java.lang, scala and scala.Predef (in that order, so the latter ones override the earlier ones).
Why is the "abstract" keyword for class definition optional in Scala, and how do I force the Scala compiler to tell me when my class is abstract?
Here an example that I wrote in Eclipse:
class Toto[T] {
def get(index: Int): T
}
object Toto {
def create[T]: Toto[T] = new Toto[T]
}
This seems to be a perfectly valid class definition in Scala, although it does NOT define the required get method, and is NOT prefixed with abstract. If you don't need the abstract keyword, then why does it exist? And if you want to be told that your class is actually abstract, how do you get the compiler to tell you?
This is not valid scala code, abstract is required, and instanciation forbidden. From the spec (5.2, p63):
The abstract modifier is used in class
definitions. It is redundant for
traits, and mandatory for all other
classes which have incomplete members.
Ab- stract classes cannot be
instantiated (ยง6.10) with a
constructor invocation unless
followed by mixins and/or a refinement
which override all incomplete members
of the class. Only abstract classes
and traits can have abstract term
members.
The code produces an error in the REPL : error: class Toto needs to be abstract, since method get is not defined
I get the proper behavior with the same message in Eclipse too. You should check whether you get the same error with and without eclipse. Whichever is true, I guess if you have exactly the code you posted without an error (does it run?), a bug repport will be warranted.
To answer my own question: In Eclipse, you can only tell if a class is correct if all other classes compile without errors! In other word, you can't trust anything Eclipse says about a class unless there are no errors in other classes.
So if you have errors in several classes, then there is no way of knowing which ones are the real errors, and neither if a class without errors is correct.
You just have to repeatedly loop on the errors, fixing any one that makes sense, and hoping the others errors that don't make sense are eventually going to just disappear.